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Abstract 


Programming  is  a  notoriously  error- prone  process,  and  a  great  deal  of  evidence  in 
practice  has  demonstrated  that  the  use  of  a  type  system  in  a  programming  language 
can  effectively  detect  program  errors  at  compile-time.  Moreover,  some  recent  studies 
have  indicated  that  the  use  of  types  can  lead  to  significant  enhancement  of  program 
performance  at  run-time.  For  the  sake  of  practicality  of  type-checking,  most  type 
systems  developed  for  general  purpose  programming  languages  tend  to  be  simple 
and  coarse,  and  this  leaves  ample  room  for  improvement.  As  an  advocate  of  types, 
this  thesis  addresses  the  issue  of  designing  a  type  system  for  practical  programming 
in  which  a  notion  of  dependent  types  is  available,  leading  to  more  accurate  capture 
of  program  invariants  with  types. 

In  contrast  to  developing  a  type  theory  with  dependent  types  and  then  designing 
upon  it  a  functional  programming  language,  we  study  practical  methods  for  extend¬ 
ing  the  type  systems  of  existing  programming  languages  with  dependent  types.  We 
present  an  approach  to  enriching  the  type  system  of  ML  with  a  special  form  of  de¬ 
pendent  types,  where  type  index  objects  are  restricted  to  some  constraint  domains 
C,  leading  to  the  DML(C)  language  schema.  The  aim  is  to  provide  for  specifica¬ 
tion  and  inference  of  significantly  more  precise  type  information  compared  with  the 
current  type  system  of  ML,  facilitating  program  error  detection  and  compiler  opti¬ 
mization.  A  major  complication  resulting  from  introducing  dependent  types  is  that 
pure  type  inference  for  the  resulting  system  is  no  longer  possible,  but  we  show  that 
type-checking  a  sufficiently  annotated  program  in  DML(C)  can  be  reduced  to  con¬ 
straint  satisfaction  in  the  constraint  domain  C.  Therefore,  type-checking  in  DML(C') 
can  be  made  practical  for  those  constraint  domains  C  for  which  efficient  constraint 
solvers  can  be  provided.  We  prove  that  DML(C)  is  a  conservative  extension  over 
ML,  that  is,  a  valid  ML  program  is  always  valid  in  DML(C).  Also  we  exhibit  the 
unobtrusiveness  of  our  approach  through  many  practical  examples.  As  a  significant 
application,  we  also  demonstrate  the  elimination  of  array  bound  checks  in  real  code 
with  the  use  of  dependent  types.  All  the  examples  have  been  verified  in  a  prototype 
implementation  of  a  type-checker  for  DML(C'),  where  C  is  some  constraint  domain 
in  which  constraints  are  linear  inequalities  on  integers.  This  is  another  attempt 
towards  refining  the  type  systems  of  existing  programing  languages,  following  the 
step  of  refinement  types  (Freeman  and  Pfenning  1991). 


To  my  parents, 

who  have  been  waiting  patiently  in  general  and  impatiently  at  the  last  moment. 


Acknowledgements 


Foremost  I  especially  thank  my  advisor  Frank  Pfenning  for  suggesting  to  me  the  wonderful  thesis 
topic.  His  sharp  criticism  on  earlier  versions  of  type-checking  algorithms  for  DML  was  inspirational 
to  the  adoption  of  the  current  bi-directional  version.  DML  would  have  been  much  less  attractive 
without  it.  I  have  thus  learned  that  a  program  can  be  trusted  only  if  it  can  be  clearly  explained. 
More  importantly,  I  have  also  developed  a  taste  for  simplicity,  which  will  surely  have  some  profound 
influence  on  my  future  research  work.  I  also  thank  him  for  his  unusual  hospitality  and  patience  in 
general. 

I  thank  Peter  Andrews  for  teaching  me  automated  theorem  proving  and  providing  me  with  the 
opportunity  to  work  as  a  research  assistant  on  TPS,  a  theorem  proving  system  based  on  higher- 
order  classic  logic.  This  really  brought  me  a  lot  of  first-hand  experience  with  writing  large  programs 
in  an  untyped  programming  language  (Common  Lisp),  and  thus  strongly  motivated  my  research 
work.  I  also  thank  him  for  his  kindness  in  general. 

I  feel  lucky  that  I  took  Robert  Harper’s  excellent  course  on  type  theory  and  programming 
languages  in  1994.  I  have  since  determined  to  do  research  related  to  promoting  the  use  of  types  in 
programming.  The  use  of  dependent  types  in  array  bound  check  elimination  was  partly  motivated 
by  a  question  he  raised  during  my  thesis  proposal.  He  also  suggested  the  use  of  dependent  types 
in  a  typed  assembly  language,  which  seems  to  be  a  highly  relevant  and  exciting  research  direction 
to  follow.  I  also  thank  him  for  his  encouragement. 

I  am  also  grateful  to  Dana  Scott  for  his  generous  and  timely  help,  and  for  his  kindness  in 
general,  which  I  shall  always  look  up  to. 

Thanks  to  Peter  Lee  and  George  Necula  for  providing  me  with  interesting  examples.  Thanks  to 
Rowan  Davies  and  Chad  Brown  for  both  helpful  technical  and  interesting  non-technical  discussions. 

Thanks  to  Feng  Tang  for  her  enduring  many  hardships  together.  Also  thanks  to  my  parents 
for  their  being  so  patient,  who  once  reasonably  hoped  that  I  could  obtain  a  Ph.D  degree  before 
their  retirement.  Instead,  they  have  now  retired  for  several  years. 


Contents 


1  Introduction  1 

1.1  Introductory  Examples .  1 

1.2  Basic  Overview .  6 

1.3  Related  Work .  8 

1.3.1  Constructive  Type  Theory  and  Related  Systems  .  8 

1.3.2  Computational  Logic  PX  .  9 

1.3.3  The  Calculus  of  Constructions  and  Related  Systems .  9 

1.3.4  Software  Model  Checking .  10 

1.3.5  Extended  ML .  11 

1.3.6  Refinement  Types  .  11 

1.3.7  Shape  Analysis .  11 

1.3.8  Sized  Types .  11 

1.3.9  Indexed  Types .  11 

1.3.10  Cayenne .  12 

1.4  Research  Contributions  .  12 

1.5  Thesis  Outline  .  13 

2  Preliminaries  15 

2.1  Untyped  A-calculus  with  Pattern  Matching  .  15 

2.1.1  Dynamic  Semantics  .  17 

2.2  Mini-ML  with  Pattern  Matching .  19 

2.2.1  Static  Semantics .  20 

2.2.2  Dynamic  Semantics  .  23 

2.2.3  Soundness .  24 

2.3  Operational  Equivalence .  26 

2.4  Summary .  32 

3  Constraint  Domains  35 

3.1  The  General  Constraint  Language  .  35 

3.2  A  Constraint  Domain  over  Algebraic  Terms .  38 

3.3  A  Constraint  Domain  over  Integers .  40 

3.3.1  A  Constraint  Solver  for  Linear  Inequalities  .  40 

3.3.2  An  Example  .  42 

3.4  Summary .  43 


1 


2 


CONTENTS 


4  Universal  Dependent  Types  45 

4.1  Universal  Dependent  Types .  45 

4.1.1  Static  Semantics .  47 

4.1.2  Dynamic  Semantics  .  51 

4.2  Elaboration .  59 

4.2.1  The  External  Language  DMLo(C)  for  MLq  (C) .  59 

4.2.2  Elaboration  as  Static  Semantics .  60 

4.2.3  Elaboration  as  Constraint  Generation .  66 

4.2.4  Some  Informal  Explanation  on  Constraint  Generation  Rules .  72 

4.2.5  An  Example  on  Elaboration .  73 

4.2.6  Elimination  of  Existential  Variables  .  77 

4.3  Summary .  78 

5  Existential  Dependent  Types  81 

5.1  Existential  Dependent  Types .  81 

5.2  Elaboration .  85 

5.2.1  Coercion .  88 

5.2.2  Elaboration  as  Static  Semantics .  93 

5.2.3  Elaboration  as  Constraint  Generation .  97 

5.3  Summary .  100 

6  Polymorphism  103 

6.1  Extending  MLo  to  MLq  .  103 

6.1.1  Static  Semantics .  104 

6.1.2  Dynamic  Semantics  .  105 

6.2  Extending  MLq ’S(C)  to  MLo’n’S(C) .  107 

6.2.1  Static  Semantics .  108 

6.2.2  Dynamic  Semantics  .  Ill 

6.2.3  Elaboration .  113 

6.2.4  Coercion .  115 

6.3  Summary .  116 

7  Effects  117 

7.1  Exceptions  .  117 

7.1.1  Static  Semantics .  117 

7.1.2  Dynamic  Semantics  .  118 

7.2  References .  120 

7.2.1  Static  Semantics .  121 

7.2.2  Dynamic  Semantics  .  121 

7.3  Value  Restriction .  125 

7.4  Extending  MLo)exc,ref  with  Polymorphism  and  Dependent  Types  .  127 

7.5  Elaboration .  133 

7.6  Summary .  133 


CONTENTS 


3 


8  Implementation  135 

8.1  Refinement  of  Built-in  Types .  135 

8.2  Refinement  of  Datatypes .  136 

8.3  Type  Annotations  .  137 

8.4  Program  Transformation .  139 

8.5  Indeterminacy  in  Elaboration .  139 

8.6  Summary .  140 

9  Applications  141 

9.1  Program  Error  Detection  .  141 

9.2  Array  Bound  Check  Elimination  .  143 

9.2.1  Experiments  .  144 

9.3  Potential  Applications .  147 

9.3.1  Dead  Code  Elimination .  147 

9.3.2  Loop  Unrolling .  149 

9.3.3  Dependently  Typed  Assembly  Language .  151 

9.4  Summary .  152 

10  Conclusion  and  Future  Work  155 

10.1  Current  Status .  155 

10.1.1  Language  Design .  155 

10.1.2  Language  Implementation .  156 

10.2  Future  Research  in  Language  Design .  156 

10.2.1  Modules .  156 

10.2.2  Combination  of  Different  Refinements .  157 

10.2.3  Constraint  Domains .  157 

10.2.4  Other  Programming  Languages .  157 

10.2.5  Denotational  Semantics .  158 

10.3  Future  Implementations .  158 

A  DML  Code  Examples  159 

A.l  Knuth-Morris-Pratt  String  Matching .  159 

A. 2  Red/Black  Tree .  161 

A. 3  Quicksort  on  Arrays .  165 

A. 4  Mergesort  on  Lists .  170 

A. 5  A  Byte  Copy  Function .  171 


4 


CONTENTS 


List  of  Figures 


1.1  The  reverse  function  on  lists .  2 

1.2  Quicksort  on  integer  lists  .  4 

1.3  Binary  search  on  arrays .  5 

1.4  A  call-by- value  evaluator  for  simply  typed  A-calculus  (I) .  6 

1.5  A  call-by-value  evaluator  for  simply  typed  A-calculus  (II)  .  7 

2.1  The  syntax  for  A^ .  16 

2.2  The  pattern  matching  rules  for  A^  .  18 

2.3  The  evaluation  rules  for  the  natural  semantics  of  A^  .  18 

2.4  The  syntax  for  MLo  .  20 

2.5  The  typing  rules  for  patterns  in  MLo .  20 

2.6  The  typing  rules  for  MLo  .  21 

2.7  Some  evaluation  rules  for  the  natural  semantics  of  MLo  .  23 

3.1  The  sort  formation  and  sorting  rules  for  type  index  objects  .  37 

3.2  The  rules  for  satisfiability  verification  .  39 

3.3  The  signature  of  the  integer  domain  .  41 

3.4  Sample  constraints .  41 

4.1  The  syntax  for  ML^((7) .  46 

4.2  The  type  formation  rules  for  MLo .  46 

4.3  Typing  rules  for  patterns  .  47 

4.4  Typing  Rules  for  ML^C) .  48 

4.5  The  pattern  matching  rules  for  ML^(C7) .  49 

4.6  Natural  Semantics  for  MLq  (C) .  52 

4.7  The  definition  of  erasure  function  ||  •  |j .  54 

4.8  The  elaboration  rules  for  patterns .  61 

4.9  The  elaboration  rules  for  ML^((7)  (I)  63 

4.10  The  elaboration  rules  for  ML^((7)  (II) .  64 

4.11  The  constraint  generation  rules  for  ML^(C)  (I) .  68 

4.12  The  constraint  generation  rules  for  ML^(C)  (II)  .  69 

4.13  The  rules  for  eliminating  existential  variables .  79 

5.1  The  derivation  rules  for  coercion .  89 

5.2  The  constraint  generation  rules  for  coercion .  92 

5.3  The  elaboration  rules  for  MLq ’S(C)  (I)  94 


5 


6 


LIST  OF  FIGURES 

5.4  The  elaboration  rules  for  MLq 'S(C)  (II) .  95 

n  s 

5.5  The  constraint  generation  rules  for  ML0  ’  (C)  (I) .  98 

n  e 

5.6  The  constraint  generation  rules  for  ML0  ’  {C)  (II)  .  99 

6.1  Type  formation  rules  for  MLq .  104 

6.2  Typing  rules  for  pattern  matching  in  MLq .  105 

6.3  Typing  Rules  for  MLq .  106 

6.4  Type  formation  rules  for  MLg'n,S(C') .  108 

6.5  Typing  rules  for  patterns  .  109 

6.6  Typing  Rules  for  MLq’II’S(C') .  110 

6.7  The  inference  rules  for  datatype  constructor  status .  115 

7.1  The  natural  semantics  for  MLg.exc  (I) .  118 

7.2  The  natural  semantics  for  MLo.exc  (II) .  119 

7.3  The  natural  semantics  for  MLo)exc,ref  (I) .  122 

7.4  The  natural  semantics  for  MLq  exc  ref  (II) .  123 

7.5  The  syntax  for  MLg(^ref(C') .  128 

7.6  Additional  typing  rules  for  MLg’^ref(C')  .  129 

7.7  Additional  evaluation  rules  for  MLg’^’(7ref(C')  .  129 

7.8  Some  elaboration  rules  for  references  and  exceptions .  134 

8.1  Dependent  types  for  some  built-in  functions .  136 

9.1  The  red/black  tree  data  structure .  142 

9.2  The  dot  product  function .  144 

9.3  Dec  Alpha  3000/600  using  SML  of  NJ  working  version  109.32  .  147 

9.4  Sun  Sparc  20  using  MLWorks  version  1.0 .  148 

9.5  loop  unrolling  for  sumArray .  151 

9.6  The  C  version  of  dotprod  function .  152 

9.7  The  DTAL  version  of  dotprod  function .  153 


Chapter  1 

Introduction 


Types  play  a  pivotal  role  in  the  design  and  implementation  of  programming  languages.  The  use 
of  types  for  catching  program  errors  at  compile-time  goes  back  to  the  early  days  of  FORTRAN.  A 
compelling  reason  for  this  practice  is  briefly  explained  in  the  following  quote. 

Unfortunately  one  often  pays  a  price  for  [languages  which  impose  no  discipline  of  types] 
in  the  time  taken  to  find  rather  inscrutable  bugs — anyone  who  mistakenly  applies  CDR 
to  an  atom  in  LISP  and  finds  himself  absurdly  adding  a  property  list  to  an  integer,  will 
know  the  symptoms.  -  Robin  Milner 

A  Theory  of  Type  Polymorphism  in  Programming  (Milner  1978) 

It  is  also  well-known  that  a  well-designed  type  system  such  as  that  of  ML  (Milner,  Tofte,  and 
Harper  1990)  can  effectively  enable  the  programmer  to  catch  numerous  program  errors  at  compile- 
tirne.  However,  there  are  also  various  occasions  in  which  many  common  program  errors  cannot 
be  caught  by  the  type  system  of  ML.  For  instance,  the  error  of  taking  the  first  element  out  of  an 
empty  list  cannot  be  caught  by  the  type  system  of  ML  because  it  does  not  distinguish  empty  lists 
from  non-empty  ones. 

The  use  of  types  for  compiler  optimization,  such  as  passing  types  to  a  polymorphic  function  to 
help  eliminate  boxing  and/or  tagging  objects,  is  a  much  more  recent  discovery.  However,  the  type 
system  of  ML  is  also  inadequate  in  this  direction.  For  instance,  it  is  desirable  to  express  the  type 
of  a  safe  array  access  operation  since  a  compiler  can  then  eliminate  run-time  array  bound  checks 
after  type-checking,  but  it  is  not  clear  how  to  do  this  in  the  current  type  system  of  ML. 

In  the  rest  of  this  chapter  we  use  concrete  examples  to  illustrate  the  advantage  of  enriching  the 
type  system  of  ML  with  dependent  types.  We  also  describe  the  context  in  which  this  thesis  exists, 
and  then  outline  the  rest  of  the  thesis. 

1.1  Introductory  Examples 

In  this  section  we  present  several  introductory  examples  to  illustrate  the  expressiveness  of  the  type 
system  which  we  will  soon  formulate  and  study.  We  suggest  that  the  reader  pay  further  attention 
to  these  examples  when  studying  the  theoretical  core  of  the  thesis  later.  Some  larger  examples  can 
be  found  in  Appendix  A. 

Notice  that  a  correct  implementation  of  a  reverse  function  on  lists  should  return  a  list  of  the 
same  length  as  that  of  its  argument.  Unfortunately,  this  property  cannot  be  captured  by  the  type 
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datatype  ’a  list  =  nil  |  cons  of  ’a  *  ’a  list 

typeref  ’a  list  of  nat  (*  indexing  datatype  ’a  list  with  nat  *) 
with  nil  <|  ’a  list(O) 

I  cons  <|  {n:nat]-  ’a  *  ’a  list(n)  ->  'a  list(n+l) 

fun( ’ a) 

reverse(l)  = 
let 

fun  rev (nil,  ys)  =  ys 

I  rev(cons(x,  xs) ,  ys)  =  rev(xs,  cons(x,  ys)) 
where  rev  <|  {m:nat]-(n:nat}-  ’a  list(m)  *  ’a  list(n)  ->  ’a  list(m+n) 
in  rev(l,  nil)  end 

where  reverse  <|  {n:nat}  'a  list(n)  ->  ’a  list(n) 


Figure  1.1:  The  reverse  function  on  lists 

system  of  ML.  The  inadequacy  can  be  remedied  if  we  introduce  dependent  types.  The  example  in 
Figure  1.1  is  written  in  the  style  of  Standard  ML  with  some  annotations,  which  will  be  explained 
shortly.  We  assume  that  we  are  working  over  the  constraint  domain  of  natural  numbers  with 
constants  0  and  1  and  addition  operation  +.  The  polymorphic  datatype  ’a  list  is  defined  to 
represent  the  type  of  lists.  This  datatype  is  indexed  by  a  natural  number,  which  stands  for  the 
length  of  a  list  in  this  case.  The  constructors  associated  with  the  datatype  ’a  list  are  then 
assigned  dependent  types: 

•  nil  <|  'a  list(O)  states  that  nil  is  a  list  of  length  0. 

•  cons  <|  {n:nat}  ’a  *  ’a  list(n)  ->  ’a  list  (n+1)  states  that  cons  yields  a  list  of  length 
n  +  1  when  given  a  pair  consisting  of  an  element  and  a  list  of  length  n.  Note  that  {n:nat} 
means  that  n  is  universally  quantified  over  natural  numbers,  usually  written  as  Iln  :  nat. 

The  use  of  fun  (’a)  is  a  recent  feature  of  Standard  ML  (Milner,  Tofte,  Harper,  and  MacQueen 
1997),  which  allows  the  programmer  to  explicitly  control  the  scope  of  the  type  variable  'a.  The 
type  of  reverse  is 

{n:nat]-  'a  list(n)  ->  ’a  list(n), 

which  states  that  reverse  always  returns  an  a  list  of  length  n  if  given  one  of  length  n.  In  this  way, 
we  have  captured  the  information  that  the  function  reverse  is  length-preserving.  Notice  that  we 
have  also  assigned  the  auxiliary  function  rev  the  following  dependent  type, 

{m:nat}{n:nat}  ’a  list(m)  *  ’a  list(n)  ->  ’a  list(m+n) 

that  is,  rev  always  returns  a  list  of  length  m  +  n  when  given  a  pair  of  lists  of  lengths  rn  and  n. 
respectively.  This  invariant  must  be  provided  in  order  to  type-check  the  entire  code. 

The  next  example  in  Figure  1.2  implements  a  quicksort  function  on  intlist.  The  datatype 
intlist,  which  represents  an  integer  list,  is  indexed  by  an  integer  which  stands  for  the  sum  of  all 
elements  in  the  integer  list.  The  following  type  of  quicksort 


{sum:int}  intlist (sum)  ->  intlist (sum) 
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states  that  the  the  sum  of  all  elements  in  the  output  intlist  of  the  function  always  equals  the 
sum  of  all  elements  in  its  input  intlist.  Therefore,  if  one  mistakenly  writes 

par(x,  intCons(x,left) , right,  ys)  instead  of  par(x,  intCons(y,left) ,  right,  ys), 

the  error,  which  is  not  unusual,  can  be  captured  in  the  enriched  type  system.  Notice  that  this  error 
slips  through  the  current  type  system  of  ML. 

The  above  examples  exhibit  some  potential  use  of  dependent  types  in  compile-time  program 
error  detection.  We  now  show  some  potential  use  of  dependent  types  in  compiler  optimization. 
The  example  in  Figure  1.3  implements  a  binary  search  function  on  a  polymorphic  array.  The 
asserted  type  of  the  subscript  function  sub  precisely  states  that  it  returns  an  element  of  type  J  a 
when  given  an  J  a  array  of  size  n  and  and  an  integer  equal  to  i  such  that  0  <  i  <  n  holds.  Clearly, 
if  the  subscript  function  sub  of  this  type  is  called,  there  is  no  need  for  inserting  run-time  array 
bound  checks  for  checking  possible  memory  violations.  This  not  only  enhances  the  robustness  of 
the  code  but  also  its  efficiency,  illustrating  that  safety  and  efficiency  issues  can  be  complementary, 
sometimes. 

Note  that  the  programmer  has  to  provide  an  appropriate  type  for  the  inner  function  look  in 
order  to  have  the  code  type-checked  successfully.  We  will  come  back  to  this  point  later. 

There  is  a  common  feature  in  the  above  three  examples,  that  is  all  the  type  index  objects  are 
drawn  from  the  integer  constraint  domain.  The  next  example  in  Figure  1.4  and  Figure  1.5  shows 
that  we  can  also  index  datatypes  with  type  index  objects  drawn  from  different  constraint  domains. 
Since  this  example  is  considerably  involved,  we  present  some  detailed  explanation. 

The  datatype  simple_type  represents  simple  types  in  a  simply  typed  A-calculus.  The  datatype 
type  context  is  basically  a  list  of  simple  types,  which  is  used  to  assigns  types  to  free  variables  in 
a  A-expression.  The  datatype  lambda_exp  is  for  formulating  simply  typed  A-expressions  in  the  de 
Bruijn’s  notation  (de  Bruijn  1980).  For  instance,  XxXy.y(x)  can  be  represented  as 

Abs(Abs(App(0ne,  Shift (One) ))) . 

The  datatypes  closure  and  enviroment  are  defined  mutually  recursively.  An  environment  is  a 
list  of  closures  and  a  closure  is  a  A-abstraction  associated  with  an  environment  which  binds  every 
free  variable  in  the  A-abstraction  to  some  closure. 

We  now  refine  some  of  these  datatype  types  into  dependent  types  in  Figure  1.4.  The  datatype 
lambda_exp  is  made  dependent  on  a  pair  (t ,  ctx) ,  where  t  stands  for  the  simple  type  of  a  lambda- 
expression  under  the  context  ctx.  Then  we  assign  dependent  types  to  the  constructors  associated 
with  the  datatype  lambda_exp.  For  instance,  the  dependent  type  of  App  states  that  App  yields  an 
A-expression  of  type  tb  under  context  ctx  if  given  a  pair  of  A-expressions  of  types  Fun(ta,tb)  and 
ta  under  context  ctx,  respectively. 

The  datatype  closure  is  made  dependent  on  an  index  drawn  from  the  type  simple_type, 
which  stands  for  the  type  of  a  closure.  Also  the  datatype  environment,  is  made  dependent  on  an 
index  drawn  from  the  type  context,  which  is  a  list  of  simple  types  corresponding  to  the  list  of 
closures  in  the  environment. 

We  assign  the  function  call_by_ value  the  following  type 

{t : simple_type}  lambda_exp(t ,  CTXempty)  ->  closure (t) 

which  states  that  this  function  always  returns  a  closure  of  type  t  when  given  an  argument  of 
type  lambda_exp(t, CTXempty),  i.e. ,  a  closed  A-expression  of  type  t.  This  simply  means  that  this 
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datatype  intlist  =  intNil  |  intCons  of  int  *  intlist 

typeref  intlist  of  int  (*  sum  *) 
with  intNil  <|  intlist (0) 

I  intCons  <|  {i:nat,  sum: int]-  int(i)  *  intlist (sum)  ->  intlist (i+sum) 
fun  intAppend(intNil ,  rs)  =  rs 

I  intAppend( intCons (1 ,  Is),  rs)  =  intCons(l,  intAppend(ls ,  rs)) 
where  intAppend  <|  {sm:int,  sn:int}  intlist (sm)  *  intlist (sn)  ->  intlist (sm+sn) 

fun  quicksort (intNil)  =  intNil 
I  quicksort (intCons (x,xs))  = 
let 

fun  par(x,  left,  right,  intNil)  = 

intAppend (quicksort (lef t) ,  intCons (x, quicksort (right) ) ) 

I  par(x,  left,  right,  intCons (y ,ys) )  = 

if  y  <=  x  then  par(x,  intCons (y, lef t) ,  right,  ys) 
else  par(x,  left,  intCons (y, right) ,  ys) 
where  par  <|  {i:int,  sp:int,  sq:int,  sr:int} 

int(i)  *  intlist (sp)  *  intlist (sq)  *  intlist (sr)  -> 
intlist (i+sp+sq+sr) 
in  par(x,  intNil,  intNil,  xs)  end 
where  quicksort  <|  {sum: int}  intlist (sum)  ->  intlist (sum) 


Figure  1.2:  Quicksort  on  integer  lists 
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datatype  ’a  answer  =  NONE  |  SOME  of  int  *  ’a 

assert  sub  <|  -[n:nat,  i :  int  |  0  <=  i  <  n  }  ’a  array(n)  *  int(i)  ->  ’a 
assert  length  <|  {n:nat}  ’a  array (n)  ->  int(n) 

fun( ’a) {size :nat} 
bsearch  cmp  (key,  arr)  = 
let 

fun  look(lo,  hi)  = 
if  hi  >=  lo  then 
let 

val  m  =  (hi  +  lo)  div  2 
val  x  =  sub (arr,  m) 
in 

case  cmp (key,  x)  of 

LESS  =>  look(lo,  m-1) 

I  EQUAL  =>  S0ME(m,  x) 

I  GREATER  =>  look(m+l,  hi) 

end 

else  NONE 

where  look  <|  {l:nat,  h:int  |  0  <=  1  <=  size  /\  0  <=  h+1  <=  size  } 
int(l)  *  int(h)  ->  ’a  answer 
in 

look  (0,  length  arr  -  1) 

end 

where  bsearch  <|  (’a  *  ’a  ->  order)  ->  ’a  *  ’a  array (size)  ->  ’a  answer 

Figure  1.3:  Binary  search  on  arrays 
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datatype  simple_type  =  Base  of  int  I  Fun  of  simple_type  *  simple_type 

datatype  context  =  CTXempty  |  CTXcons  of  simple_type  *  context 

datatype  lambda_exp  = 

One  |  Shift  of  lambda_exp  | 

Abs  of  lambda_exp  | 

App  of  lambda_exp  *  lambda_exp 

typeref  lambda_exp  of  simple_type  *  context 

with  One  <|  {t :  simple_typeMctx :  context}  lambda_exp(t ,  CTXcons  (t,ctx)) 

I  Shift  <|  {ta:  simple_type]-{tb :  simple_type}{ctx:  context }- 

lambda_exp(ta,ctx)  ->  lambda_exp (ta, CTXcons (tb.ctx)) 

I  Abs  <|  {ta:  simple_type]-{tb :  simple_type]-{ctx :  context } 
lambda_exp(tb, CTXcons (ta,ctx))  -> 
lambda_exp(Fun(ta,tb) ,ctx) 

I  App  <|  {ta:  simple_type}{tb :  simple_type]-{ctx :  context } 

lambda_exp(Fun(ta,tb) , ctx)  *  lambda_exp(ta, ctx)  ->  lambda_exp(tb, ctx) 

datatype  closure  =  Closure  of  lambda_exp  *  environment 

and  environment  =  ENVempty  |  ENVcons  of  closure  *  environment 

typeref  closure  of  simple_type 

with  Closure  <|  {t : simple_type}{ctx: context } 

lambda_exp(t , ctx)  *  environment (ctx)  ->  closure (t) 
and  environment  of  simple_type  *  context 
with  ENVempty  < |  environment (CTXempty) 

I  ENVcons  <|  {t : simple_type}{ctx : context } 

closure (t)  *  environment (ctx)  ->  environment (CTXcons (t , ctx) ) 


Figure  1.4:  A  call-by- value  evaluator  for  simply  typed  A-calculus  (I) 


implementation  of  an  evaluator  for  the  pure  simply  typed  call-by-value  A-calculus  a  la  Curry  typing 
is  a  type-preserving  function.  Clearly,  the  programmer  should  have  much  more  confidence  in  the 
correctness  of  the  function  call_by_value  after  the  code  passes  type-checking. 

1.2  Basic  Overview 

We  outline  in  this  section  the  historic  context  in  which  this  thesis  is  developed,  and  mention  some 
related  work  in  the  next  section. 

The  problem  of  correctness  of  programs  is  ever  present  in  programming.  There  has  been  a  long 
history  of  research  work  on  program  verification. 

The  use  of  assertions  to  specify  and  prove  correctness  of  flowchart  programs  was  developed 
independently  by  Naur  (Naur  1966)  and  Floyd  (Floyd  1967).  Hoare  then  constructed  a  partial- 
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fun  call_by_value (e)  = 
let 

fun  cbv(One,  ENVcons(clo,  env))  =  clo 

I  cbv(Shift (e) ,  ENVcons(clo,  env))  =  cbv(e,  env) 

I  cbv(Abs(e),  env)  =  Closure (Abs (e) ,  env) 

I  cbv(App(f,  e) ,  env)  = 
let 

val  Closure (Abs (body) ,  fenv)  =  cbv(f,  env) 
val  clo  =  cbv(e,  env) 
in 

cbv(body,  ENVcons(clo,  fenv)) 
end 

where  cbv  <|  {t : simple_type ,  ctx: context } 

lambda_exp(t , ctx)  *  environment (ctx)  ->  closure(t) 
in 

cbv(e,  ENVempty) 
end 

where  call_by_value  <|  {t : simple_type}  lambda_exp(t ,  CTXempty)  ->  closure (t) 


Figure  1.5:  A  call-by-value  evaluator  for  simply  typed  A-calculus  (II) 


correctness  system  (Hoare  1969)  which  brought  us  Hoare  logic.  Then  Dijkstra  invented  the  notion 
of  weakest  preconditions  (Dijkstra  1975)  and  explored  it  in  more  details,  with  many  examples, 
in  (Dijkstra  1976).  As  a  generalization  of  the  weakest-precondition  approach,  refinement  logics 
have  become  an  active  research  area  in  recent  years.  These  approaches  are  in  general  notoriously 
difficult  and  expensive  to  put  into  software  practice.  Only  small  pieces  of  safety  critical  software 
can  afford  to  be  formally  verified  with  such  approaches.  Although  rapid  progress  has  been  made, 
there  are  still  strong  reservations  on  whether  daily  practical  programming  can  benefit  much  from 
these  approaches.  However,  these  approaches  are  gaining  grounds  in  the  verification  of  hardware. 

For  functional  programming  languages  we  find  two  principal  styles  of  reasoning:  equational  and 
logical. 

Equational  reasoning  is  performed  through  program  transformation,  which  has  its  roots  in 
(Church  and  Rosser  1936).  Burstall  and  Darlington  presented  a  transformation  system  for  devel¬ 
oping  recursive  programs  (Burstall  and  Darlington  1977).  Also  we  have  Bird-Meertens  calculus 
for  derivation  of  functional  programs  from  a  specification  (Bird  1990),  which  consists  of  a  set  of 
higher-order  functions  that  operate  on  lists  including  map,  fold,  scan,  filter,  inits,  tails,  cross  prod¬ 
uct  and  function  composition.  Equational  reasoning  also  plays  a  fundamental  role  in  FP  and  EML 
(Kahrs,  Sannella,  and  Tarlecki  1994). 

Logical  reasoning  is  most  often  cast  into  type  theory,  which  has  its  roots  in  (Church  1940; 
Martin-Lof  1984).  This  approach  emphasizes  the  joint  development  of  proofs  and  programs.  Many 
systems  such  as  NuPrl  (Constable  et  al.  1986),  Coq  (Coquand  1991),  LEGO  (Pollack  1994),  ALF 
(Augustsson,  Coquand,  and  Nordstrom  1990)  and  PVS  (Shankar  1996)  are  based  on  some  variants 
of  type  theory,  though  this  can  also  be  done  in  a  “type-free”  setting  as  shown  in  PX  (Hayashi 
and  Nakano  1988).  However,  recently  it  has  also  been  used  to  generate  post-hoc  proofs  and  proof 
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skeletons  from  functional  programs  together  with  specifications  (Parent  1995). 

There  are  several  major  difficulties  associated  with  type-theoretic  approaches. 

1.  Languages  tend  to  be  unrealistically  small.  Although  pure  type  systems  (Barendregt  1992) 
can  be  formulated  concisely  and  elegantly,  they  contain  too  few  language  constructs  to  sup¬ 
port  practical  programming. 

2.  It  is  unwieldy  to  add  programming  features  into  pure  type  theories.  This  is  attested  in  the 
works  such  as  allowing  unlimited  recursion  (Constable  and  Smith  1987),  introducing  recursive 
types  (Mendler  1987),  and  incorporating  effects  (Honsell,  Mason,  Smith,  and  Talcott  1995), 
exceptions  (Nakano  1994)  and  input/output. 

3.  Type-checking  is  usually  un decidable  in  systems  enriched  with  recursion  and  dependent  types. 
Therefore,  type-checking  programs  requires  a  certain  level  of  theorem  proving.  For  systems 
such  as  NuPrl  and  PVS,  type-checking  is  interactive  and  may  often  become  a  daunting  task 
for  programmers. 

4.  It  is  heuristic  at  best  to  do  theorem  proving  by  tactics  during  type-checking,  and  this  requires 
a  lot  of  user  interactions.  Since  small  changes  in  program  may  often  mean  a  big  change  in 
a  proof  and  there  are  many  changes  to  be  made  during  the  program  development  cycle,  the 
cost  in  effort  and  time  often  deters  the  user  from  programming  in  such  a  setting. 

Instead,  we  propose  to  enrich  the  type  systems  of  an  existing  functional  programming  language 
(ML).  In  contrast  to  adjusting  programming  language  features  such  as  recursion,  effects  and  ex¬ 
ceptions  to  a  type  theory,  we  study  approaches  to  adjusting  a  type  theory  to  these  programming 
language  features.  We  refine  ML  types  with  dependent  types  and  introduce  a  restricted  form  of  de¬ 
pendent  types,  borrowing  ideas  from  type  theory.  This  enables  us  to  assert  additional  properties  of 
programs  in  their  types,  providing  significantly  more  information  for  program  error  detection  and 
compiler  optimization.  In  order  to  make  type-checking  manageable  in  this  enriched  type  system, 
we  require  that  type  dependencies  be  taken  from  some  restricted  constraint  domain  C,  leading  to 
the  DML(C)  language  schema.  We  then  prove  that  type-checking  a  sufficiently  annotated  program 
in  DML(C)  can  be  reduced  to  constraint  satisfaction  in  the  constraint  domain  C.  An  immediate 
consequence  of  this  reduction  is  that  if  we  choose  C  to  be  some  relative  simple  constraint  domains 
for  which  there  are  practical  approaches  to  solving  constraints,  then  we  can  construct  a  practical 
type-checking  algorithm  for  DML(C).  We  will  focus  on  the  case  where  C  is  some  integer  constraint 
domain  in  which  the  constraints  are  linear  inequalities  on  integers. 

1.3  Related  Work 

It  is  certainly  beyond  reasonable  hope  to  mention  even  a  moderate  part  of  the  research  on  the 
correctness  of  programs.  This  is  simply  because  of  the  vastness  of  the  field.  We  shall  examine 
some  efforts  which  have  a  close  connection  to  our  work,  mostly  concerning  type  theories  and  their 
applications.  We  start  with  Martin-Lof’s  constructive  type  theory. 

1.3.1  Constructive  Type  Theory  and  Related  Systems 

The  system  of  constructive  type  theory  is  based  primarily  on  the  work  of  Per  Martin-Lof  (Martin- 
Lof  1985;  Martin-Lof  1984).  Its  core  idea  often  reads  propositions  as  types.  This  is  a  system  which 
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is  simultaneously  a  logic  and  a  programming  language.  Programs  are  developed  in  such  a  way  that 
they  must  behave  according  to  their  specifications.  This  is  achieved  through  formal  proofs  which 
are  written  within  the  programs.  The  correctness  of  these  proofs  is  verified  by  type-checkers. 

NuPrl  The  NuPrl  proof  system  was  developed  to  allow  the  extraction  of  programs  from  the  proof 
of  specifications  (Constable  et  al.  1986).  Its  logical  basis  is  a  sequent-calculus  formulation  of  a 
descendant  of  constructive  type  theory.  Similarly  to  LCF  it  features  a  goal-oriented  proof  engine 
employing  tactics  formulated  in  the  ML  programming  language.  The  emphasis  of  NuPrl  is  logical, 
in  that  it  is  designed  to  support  the  top-down  construction  of  derivations  of  propositions  in  a 
deduction  system. 

ALF  The  ALF  (Another  Logical  Framework)  system  is  an  interactive  proof  editing  environment 
where  proof  objects  for  mathematical  theorems  are  constructed  on  screen.  It  is  based  on  Martin- 
Lof’s  monomorphic  type  theory  (Augustsson,  Coquand,  and  Nordstrom  1990;  Nordstrom  1993). 
The  proof  editor  keeps  a  theory  environment,  a  dictionary  with  abbreviations  and  a  scratch  area. 
The  user  navigates  in  the  scratch  area  to  build  proofs  in  top-down  and/or  bottom-up  fashion.  A 
novelty  of  ALF  lies  in  its  use  of  pattern  matching  with  dependent  types  (Coquand  1992)  for  defining 
functions.  The  totality  of  functions  defined  by  pattern  matching  is  guaranteed  by  some  restrictions 
on  recursive  equational  definitions.  This  allows  the  user  to  formulate  significantly  shorter  proofs 
in  ALF  than  in  many  other  systems. 

1.3.2  Computational  Logic  PX 

Realizability  models  of  intuitionistic  formal  systems  also  allow  the  extraction  of  computations 
from  the  systems.  PX  is  such  a  system  which  is  introduced  in  (Hayashi  1990)  and  described 
in  detail  in  (Hayashi  and  Nakano  1988).  PX  is  a  logic  for  a  type-free  theory  of  computation 
based  on  Feferman’s  Tq  (Feferman  1979),  from  which  LISP  programs  are  extracted  by  a  notion  of 
realizability:  PX-realizability.  Hayashi  argues  that  the  requirement  that  a  theory  be  total  is  too 
restrictive  for  practical  programming,  in  justification  of  his  logic  being  based  around  a  system  of 
possibly  nonterminating  computations. 

Also  Hayashi  proposed  a  type  system  ATTT  in  (Hayashi  1991),  which  allows  a  notion  of  re¬ 
finement  types  as  in  the  type  system  for  ML  (Freeman  and  Pfenning  1991),  plus  intersection  and 
union  of  refinement  types  and  singleton  refinement  types.  He  demonstrated  that  singleton,  union 
and  intersection  types  allow  the  development  of  programs  without  unnecessary  coding  via  a  variant 
of  the  Curry-Howard  isomorphism.  More  exactly,  they  give  a  way  to  write  types  as  specifications 
of  programs  without  unnecessary  coding  which  is  inevitable  otherwise. 

1.3.3  The  Calculus  of  Constructions  and  Related  Systems 

Calculus  of  Constructions  and  Coq  The  calculus  of  constructions  (CC)  is  a  type  system  which 
basically  enriches  Girard’s  Fu  with  types  dependent  on  terms.  It  therefore  relates  to  Martin-Lof’s 
intuitionistic  theory  of  types  (TT)  in  this  respect.  CC  was  originally  developed  and  implemented 
by  Coquand  and  Huet  (Coquand  and  Huet  1985;  Coquand  and  Huet  1988).  Coquand  and  Paulin- 
Mohring  proposed  to  extend  CC  with  primitive  inductive  definitions  (Paulin- Mohring  1993),  which 
led  to  the  calculus  of  inductive  constructions  and  its  implementation  in  the  Coq  proof  assistant 
consisting  of  a  proof-checker  for  CC,  a  facility  called  Mathematical  Vernacular  for  the  high-level 
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notation  of  mathematical  theories,  and  an  interactive  theorem  prover  based  on  tactics  written  in 
the  Carnl  dialect  of  the  ML  language. 

Recently,  Parent  (Parent  1995)  proposed  to  reverse  the  process  of  extracting  programs  from 
constructive  proofs  in  Coq,  synthesizing,  post  hoc,  proofs  from  programs.  This  approach  has  a  close 
connection  to  ours,  in  that  we  are  trying  to  use  dependent  types  expressing  additional  properties  of 
programs  which  are  then  verified  by  a  type-checker.  Relying  on  a  weak  extraction  function  which 
produces  programs  with  annotations,  Parent  introduced  a  new  language  for  annotated  programs 
and  proved  that  partial  proof  terms  can  be  deterministically  retrieved  from  given  programs  in  this 
language  and  their  specifications.  Then  she  showed  that  such  an  extraction  function  is  invertible, 
deducing  an  algorithm  for  reconstructing  proofs  from  programs.  She  also  proved  the  validity  and 
completeness  (in  a  certain  sense)  of  this  approach.  Programs  usually  have  prohibitively  many 
annotations  in  the  new  language,  preventing  the  user  from  writing  sufficiently  natural  programs. 
A  heuristic  algorithm  for  generating  partial  proof  terms  was  then  proposed  and  implemented  in 
Coq  as  a  tactic.  This  tactic  builds  a  partial  proof  term  from  a  program  and  a  specification,  and 
then  the  usual  Coq  tactics  are  called  to  fulfill  the  proof  obligations. 

ECC  and  LEGO  The  Extended  Calculus  of  Constructions  (ECC)  (Luo  1989)  unifies  ideas  from 
Martin-Lof’s  type  theory  and  the  Calculus  of  Constructions.  In  (Lou  1991)  a  further  extension 
of  the  framework  by  datatypes  covered  with  a  general  form  of  schemata  is  proposed.  The  LEGO 
system  implements  ECC,  in  which  the  use  of  inductive  definitions  and  pattern  matching  is  appealing 
to  practical  work  on  proofs. 


1.3.4  Software  Model  Checking 

Model  checking  is  superior  to  general  theorem  proving  in  a  few  aspects.  Model  checking  need 
not  invent  lemmas  or  devise  proof  strategies,  offering  full  automation.  Also  model  checking  can 
generate  counterexamples  when  a  check  fails.  Both  software  specifications  and  their  intended 
properties  can  be  expressed  in  a  simple  relational  calculus  (Jackson,  Sornesh,  and  Damon  1996). 
The  claim  that  a  specification  satisfies  a  property  becomes  a  relational  formula  that  can  then  be 
checked  automatically  by  enumerating  the  formula’s  interpretations  if  the  number  of  interpretation 
is  finite.  Unfortunately,  in  software  designs,  state  explosion  arises  more  from  the  data  structures 
of  a  single  program  than  from  the  product  of  the  control  states  of  several  programs.  The  result  is 
that  the  number  of  different  interpretations  for  a  relational  formula  is  in  general  vastly  too  great 
for  brute-force  enumerations  to  be  feasible.  Even  worse,  it  is  quite  often  the  case  where  such  a 
formula  can  have  infinitely  many  interpretations.  In  (Jackson,  Sornesh,  and  Damon  1996),  it  is 
proposed  to  reduce  the  number  of  cases  which  a  checker  must  consider  by  eliminating  isomorphic 
interpretations.  This  strategy  has  been  successfully  tried  in  hardware  verification.  Also  with  great 
care  one  needs  to  downscale  the  state  space  of  a  system,  bring  it  into  the  reach  of  a  checker.  This 
is  based  on  the  assumption  that  if  a  bug  lies  in  the  original  system,  then  it  is  likely  to  cause  a  bug 
in  the  downscaled  system.  Experience  suggests  that  enumerating  all  behaviors  for  the  downscaled 
machine  is  a  more  reliable  debugging  method  than  exploring  merely  some  cases  for  the  original 
system. 

As  we  will  see,  if  we  choose  C  to  be  some  finite  domain  then  model  checking  seems  to  be  a 
natural  approach  to  solving  the  constraints  generated  during  type-checking  programs  in  DML(C). 


1.3.  RELATED  WORK 
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1.3.5  Extended  ML 

Sannella  and  Tarlecki  proposed  Extended  ML  (Sannella  and  Tarlecki  1989)  as  a  framework  for 
the  formal  development  of  programs  in  a  pure  fragment  of  Standard  ML.  The  module  system  of 
Extended  ML  can  not  only  declare  the  type  of  a  function  but  also  the  axioms  it  satisfies.  This  leads 
to  the  need  for  theorem  proving  during  type  checking.  We  specify  and  check  less  information  about 
functions  which  avoids  general  theorem  proving.  On  the  other  hand,  we  currently  do  not  address 
module-level  issues,  although  we  believe  that  our  approach  should  extend  naturally  to  signatures 
and  functors  without  much  additional  machinery. 

1.3.6  Refinement  Types 

Tim  Freeman  and  Frank  Pfenning  proposed  refinement  types  for  ML  (Freeman  and  Pfenning  1991). 
A  user-defined  ML  datatype  can  be  refined  into  a  finite  lattice  of  subtypes.  In  this  extension,  type 
inference  is  decidable  and  every  well-typed  expression  has  a  principal  type.  The  user  is  free  to  omit 
type  declaration  almost  everywhere  in  a  program.  A  prototype  implementation  (Freeman  1994) 
exhibits  that  this  is  a  promising  approach  to  enriching  the  type  systems  of  ML.  Our  thesis  work 
follows  the  paradigm  of  refinement  types. 

1.3.7  Shape  Analysis 

Jay  and  Sekanina  (Jay  and  Sekanina  1996)  introduced  a  technique  for  array  bounds  checking  based 
on  the  notion  of  shape  types.  Shape  checking  is  a  kind  of  partial  evaluation  and  has  very  different 
characteristics  and  source  language  when  compared  to  DML(C),  where  C  consists  of  linear  integer 
equality  and  inequality  constraints.  We  feel  that  their  design  is  more  restrictive  and  seems  more 
promising  for  languages  based  on  iteration  schemas  rather  than  general  recursion. 

1.3.8  Sized  Types 

Hughes,  Pareto  and  Sabry  (Hughes,  Pareto,  and  Sabry  1996)  introduced  the  notion  of  sized  types 
for  proving  the  correctness  of  reactive  systems.  Though  there  exist  some  similarities  between  sized 
types  and  datatype  refinement  in  DML(C)  for  some  domain  C  on  natural  numbers,  the  differences 
seem  to  be  substantial.  We  feel  that  the  language  presented  in  (Hughes,  Pareto,  and  Sabry  1996) 
is  too  restrictive  for  general  purpose  programming  since  the  type  system  there  can  only  handle  (a 
minor  variation  of)  primitive  recursion.  On  the  other  hand,  the  use  of  sized  types  in  the  correctness 
proofs  of  reactive  systems  cannot  be  achieved  in  DML  at  this  moment. 

1.3.9  Indexed  Types 

So  far  the  most  closely  related  to  our  work  is  the  system  of  indexed  types  developed  independently 
by  Zenger  in  his  forthcoming  Ph.D.  Thesis  (Zenger  1998)  (an  earlier  version  of  which  is  described 
in  (Zenger  1997)).  He  works  in  the  context  of  of  lazy  functional  programming.  His  language  is  clean 
and  elegant  and  his  applications  (which  significantly  overlap  with  ours)  are  compelling.  In  general, 
his  approach  seems  to  require  more  changes  to  a  given  Haskell  program  to  make  it  amenable  to 
checking  indexed  types  than  is  the  case  for  our  system  and  ML.  This  is  particularly  apparent  in  the 
case  of  existential  dependent  types,  which  are  tied  to  data  constructors.  This  has  the  advantage 
of  a  simpler  algorithm  for  elaboration  and  type-checking  than  ours,  but  the  program  (and  not  just 
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the  type)  has  to  be  more  explicit.  Also,  since  his  language  is  pure,  he  does  not  consider  a  value 
restriction. 


1.3.10  Cayenne 

Cayenne  (Augustsson  1998)  is  a  Haskell-like  language  in  which  fully  dependent  types  are  available, 
that  is,  language  expressions  can  be  used  as  type  index  objects.  The  steep  price  for  this  is  unde- 
cidable  type-checking  in  Cayenne.  We  feel  that  Cayenne  pays  greater  attention  to  making  more 
programs  typable  than  assigning  programs  more  accurate  types.  In  Cayenne,  the  printf  in  C, 
which  is  not  typable  in  ML,  can  be  made  typable,  and  modules  can  be  replaced  with  records,  but 
the  notion  of  datatype  refinement  does  not  exist.  This  clearly  separates  our  language  design  from 
that  of  Cayenne. 


1.4  Research  Contributions 

The  notion  of  dependent  types  has  been  around  for  at  least  three  decades,  but  it  has  not  been 
made  applicable  to  practical  programming  before.  One  major  obstacle  is  the  difficulty  in  designing 
a  practical  type-checking  algorithm  for  dependent  type  systems. 

The  main  contribution  of  this  thesis  is  that  we  convincingly  demonstrate  the  use  of  a  restricted 
form  of  dependent  types  in  practical  programming.  We  present  a  sound  and  practical  approach  to 
extending  the  type  system  of  ML  with  dependent  types,  achieving  this  through  theoretical  work, 
actual  implementation  and  evaluation.  The  following  consists  of  some  major  steps  which  lead  to 
the  substantiation  of  this  claim. 

1.  We  separate  type  index  objects  from  expressions  in  the  programming  language.  More  pre¬ 
cisely,  we  require  that  type  index  objects  be  restricted  to  some  constraint  domains  C.  We 
then  prove  that  type-checking  a  sufficiently  annotated  program  in  this  setting  can  be  reduced 
to  constraint  satisfaction  in  C.  It  is  this  crucial  decision  in  our  language  design  which  makes 
type-checking  practical  in  the  case  where  there  are  feasible  approaches  to  solving  constraints 
in  C. 

2.  We  prove  that  our  enriched  language  is  a  conservative  extension  of  ML.  Therefore,  a  program 
which  uses  no  features  of  dependent  types  behaves  exactly  the  same  as  in  ML  at  both  compile 
and  run  time. 

3.  We  show  that  dependent  types  cope  well  with  many  important  programming  features  such 
as  polymorphism,  mutable  references  and  exceptions. 

4.  We  exhibit  the  unobtrusiveness  of  dependent  types  in  practical  programming  by  writing 
programs  as  well  as  by  modifying  existing  ML  code.  Though  the  programmer  has  to  provide 
type  annotations  in  many  cases  in  order  to  successfully  type-check  the  code,  the  amount  of 
work  is  moderate  (type  annotations  usually  accounts  for  less  than  20%  of  the  entire  code). 
On  the  other  hand,  all  type  annotations  are  type-checked  mechanically,  and  therefore  they 
can  be  fully  trusted  when  used  as  program  documentation. 
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5.  We  also  demonstrate  that  the  programmer  can  supply  type  annotations  to  safely  remove 
array  bound  checks.  This  leads  to  not  only  more  robust  programs  but  also  significantly  more 
efficient  code. 

In  a  larger  scale,  the  dependent  types  also  have  the  following  potential  applications,  for  which  we 
will  provide  illustrating  examples. 

1.  The  dependent  types  in  the  source  code  can  be  passed  down  to  lower  level  languages.  For 
instance,  we  are  also  in  the  process  of  designing  a  dependently  typed  assembly  language ,  in 
which  the  dependent  types  passed  down  from  the  source  code  can  be  used  to  generate  a 
proof  asserting  the  memory  integrity  of  the  assembly  code.  Therefore,  our  source  language 
is  promising  to  act  as  a  front-end  for  generating  proof-carrying  code  (Necula  1997). 

2.  The  dependent  types  can  facilitate  the  elimination  of  redundant  matches  in  pattern  matching. 
On  one  hand,  this  can  lead  to  more  accurate  error  or  warning  message  reports  during  type¬ 
checking.  One  the  other  hand,  this  opens  an  exciting  avenue  to  dependent  type  directed  partial 
evaluation  as  shown  in  Section  9.3.2. 

1.5  Thesis  Outline 

The  rest  of  the  thesis  is  organized  as  follows. 

In  the  next  chapter,  we  start  with  an  untyped  language  which  is  basically  the  call-by-value 
A-calculus  extended  with  general  pattern  matching.  The  importance  of  this  language  lies  in  its 
operational  semantics,  to  which  we  will  relate  the  operational  semantics  of  typed  languages  for¬ 
mulated  later.  We  then  introduce  a  typed  programing  language  MLo,  which  is  basically  mini-ML 
extended  with  general  pattern  matching.  We  prove  various  well-known  properties  of  MLo,  which 
mainly  serve  as  the  guidance  for  our  further  development.  Also  we  study  the  operational  equiva¬ 
lence  relation  in  ,  which  is  later  needed  in  the  proof  of  the  correctness  of  elaboration  algorithms 
in  Chapters  4  and  5. 

The  language  enriched  with  dependent  types  will  be  parameterized  over  a  constraint  domain 

from  which  the  type  index  objects  are  drawn.  We  introduce  a  general  constraint  language  in 

Chapter  3  upon  which  a  constraint  domain  is  formulated.  We  then  present  some  concrete  examples 

of  constraint  domains,  including  the  integer  domain  needed  for  array  bound  check  elimination. 

In  Chapter  4,  we  introduce  the  notion  of  universal  dependent  types  and  extend  MLo  with  this 

form  of  types.  This  leads  to  the  programming  language  ML^C*).  We  then  prove  various  important 

properties  of  ML^C)  and  relate  its  operation  semantics  to  that  of  MLo-  This  culminates  with  the 

conclusion  that  ML^C)  is  a  conservative  extension  of  MLo-  In  order  to  show  the  unobtrusiveness 

of  universal  dependent  types  in  programming,  we  also  formulate  an  external  programming  language 

DMLo(C)  for  MLq  (C)  which  closely  resembles  that  for  mini-ML.  We  then  present  an  elaboration 

mapping  from  DMLo(C')  to  MLq  (C)  and  prove  its  correctness. 

In  Chapter  5,  we  explain  some  inadequacies  of  ML^(C)  through  examples  and  introduce  the 

notion  of  existential  dependent  types.  We  extend  ML^(C)  with  this  form  of  types  and  obtain 

the  programming  language  MLqI,S(C').  The  external  language  DMLo((7)  is  extended  accordingly. 

The  initial  development  of  this  chapter  is  parallel  to  that  of  the  previous  one.  However,  it  seems 

n  s 

difficult  to  find  an  elaboration  mapping  from  DMLo(C)  to  ML0  ’  (C)  directly.  We  point  out  the 

n  s 

difficulty  and  suggest  some  methods  to  overcome  it.  Then  an  elaboration  mapping  for  ML0  ’  ( C ) 
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is  presented  and  proven  to  be  correct.  The  theoretical  core  of  the  thesis  consist  of  Chapter  4  and 
5. 

We  study  combining  dependent  types  with  polymorphism  in  Chapter  6.  Though  the  develop¬ 
ment  of  dependent  types  is  largely  orthogonal  to  polymorphism,  there  are  still  some  practical  issues 
which  we  must  address.  We  introduce  MLq,  a  language  which  extends  MLo  with  let-polymorphism, 
and  set  up  the  machinery  for  combining  dependent  types  with  let-polymorphism.  Lastly,  we  present 

a  two-phase  elaboration  algorithm  for  achieving  full  compatibility  between  MLq  and  MLg’n’^(C'), 

n  s 

the  language  which  extends  ML0  ’  ( C )  with  let-polymorphism. 

In  Chapter  7,  we  study  the  interaction  of  dependent  types  with  effects  such  as  mutable  refer¬ 
ences  and  exceptions.  After  spotting  the  problems,  we  adopt  the  value  restriction  approach,  which 
solves  these  problems  cleanly.  We  conclude  with  the  formulation  of  a  typed  programing  language 
MLq ’^Fref  (^*)  which  includes  features  such  as  references,  exceptions,  let-polymorphism  and  depen¬ 
dent  types.  In  other  words,  we  have  finally  extended  the  core  of  ML,  that  is,  ML  without  module 
level  constructs,  with  dependent  types. 

We  describe  a  prototype  implementation  in  Chapter  8,  and  then  present  in  Chapter  9  some 
applications  of  dependent  types  which  include  program  error  detection,  array  bound  check  elimi¬ 
nation,  redundant  match  elimination,  etc.  Lastly,  we  conclude  and  point  out  some  directions  for 
future  research. 


Chapter  2 

Preliminaries 


In  this  chapter,  we  first  introduce  an  untyped  language  which  is  basically  the  call-by-value 
A-calculus  extended  with  general  pattern  matching.  The  importance  of  this  language  lies  in  its 
operational  semantics,  to  which  we  will  relate  the  operational  semantics  of  other  typed  languages 
introduced  later. 

We  then  introduce  an  explicitly  typed  language  upon  which  we  will  build  our  type  system.  We 
call  this  language  MLo,  which  is  basically  mini- ML  extended  with  pattern  matching.  We  present 
the  typing  rules  and  operational  semantics  for  MLo  and  prove  important  properties  of  MLo  such 
as  the  type  preservation  theorem,  which  are  helpful  for  understanding  what  we  develop  later. 

Lastly,  we  study  the  operational  equivalence  relation  in  A^ .  This  will  be  used  later  when 
we  prove  the  correctness  of  elaboration  algorithms  for  the  languages  MLq  {C)  and  ML^’S(C)  in 
Chapter  4  and  5. 


2.1  Untyped  A-calculus  with  Pattern  Matching 

A  crucial  point  in  many  typed  programming  languages  is  that  types  are  indifferent  to  program 
evaluation.  Roughly  speaking,  one  can  erase  all  the  type  information  in  a  program  and  evaluate  it 
to  reach  the  same  result  as  one  would  while  keeping  all  the  type  information  during  the  evaluation. 
As  matter  of  a  fact,  it  is  a  common  practice  in  many  compilers  to  discard  all  the  type  information  in 
a  program  after  type-checking  it.  However,  recent  studies  such  as  (Tarditi,  Morrisett,  Cheng,  Stone, 
Harper,  and  Lee  1996;  Morrisett,  Walker,  Crary,  and  Glew  1998)  have  demonstrated  convincingly 
that  this  practice  may  not  be  wise  because  type  information  can  be  very  helpful  for  compiler 
optimization. 

Nonetheless  it  is  necessary  for  us  to  show  that  types  do  not  alter  the  operational  semantics  of 
programs  in  the  various  typed  languages  we  formulate  later  in  this  thesis.  For  this  purpose,  we 
introduce  an  untyped  language  A^j .  We  then  define  an  operational  semantics  for  A^j  to  which 
the  operational  semantics  of  other  typed  languages  will  relate. 

The  syntax  of  A^A  is  given  in  Figure  2.1.  We  use  x,y  and  /  as  rneta  variables  for  object 
language  variables,  c  for  constructors,  e  for  expressions,  u  for  value  forms  and  v  for  values.  Value 
forms  are  a  special  form  of  values  and  values  are  a  special  form  of  expressions.  Also  we  use  p 
for  patterns  and  we  emphasize  that  a  variable  can  occur  at  most  once  in  a  given  pattern.  The 
signature  is  a  list  of  constructors  available  in  the  language. 
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patterns 

V  ■ 

:=  x  |  c  |  c(p)  |  ()  |  (pi,P2) 

matches 

ms 

:=  (jp  e)  |  (jp  =^-  e  ms) 

expressions 

e 

:=  x  |  ()  (ei,e2)  |  c(e)  |  (case  e  of  ms)  (lam  x.e)  |  ei(e2) 

let  x  =  ei  in  e2  end  (fix  f.u) 

value  forms 

u 

:=  c(u)  |  ()  |  {u\,U2)  (lam  x.e) 

values 

V 

:=  x  |  c(v)  ()  |  (ui,u2)  |  (lam  x.e) 

signatures 

S 

:=  •  5,  c 

substitutions 

0  : 

:=  []  0[x  1— >  e] 

Figure  2.1:  The  syntax  for 


The  set  FV(e)  of  free  variables  in  an  expression  e  is  defined  as  follows. 


FV(x) 

FV((}) 

FV(c) 
FV(c(e)) 
FV(p  =►  e) 
FV(p  =$■  e  |  ms) 
FV(case  e  of  ms) 
FV(lam  x.e) 
FV(ei(e2)) 

FV(let  x  =  e\  in  end) 
FV(fix  f.u ) 


M 

0 


FV(e) 

FV(e)\FV(p) 

FV(p  e)  U  FV(ms) 
FV(e)  U  FV(ms) 
FV(e)\{x} 

FV(ei)  UFV(e2) 
FV(ei)  U  (FV(e2)\{x}) 

F  V(«)\{/} 


Substitutions  are  defined  in  the  standard  way.  We  write  e[9\  as  the  result  of  applying  substitu¬ 
tion  6  to  e.  Since  we  allow  substituting  an  expression  containing  free  variables  for  a  variable,  we 
emphasize  that  a-conversion  is  always  performed  if  necessary  to  avoid  capturing  free  variables. 

We  use  dom(0)  for  the  domain  of  substitution  6.  If  x  0  dom(0),  we  use  9[x  i— ►  e]  for  the 
substitution  O'  such  that  dom(0/)  =  dom(0)  U  {x}  and 


o\y) 


0(y)  if  y  is  not  x; 
e  if  y  is  x. 


We  use  []  for  the  empty  substitution  0,  and  [x  i— >  e]  for  the  substitution  0  such  that  dom(6l)  =  {x} 
and  0(x)  =  e.  Let  0\  and  62  be  two  substitutions  such  that  dom(#i)  fi  dom($2)  =  0-  We  define 
8\  U  02,  the  union  of  9\  and  O2,  as  the  substitution  0  such  that  dom(0)  =  dom(0i)  U  dom(02)  and 


0(x) 


0 i(x)  if  x  6  dom(0i); 
02 (x)  if  x  G  dom(02)- 


Similarly,  0\  o  02,  the  composition  of  0\  and  02,  is  defined  as  the  substitution  6  such  that  dom(0)  = 
dom(0i)  U  dom(02),  and 


0(x)  = 


(0i(x))[02]  if  x  G  dom(0i); 
&2(x)  if  x  G  dom(02)- 
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A  substitution  9  is  called  a  value  substitution  if  9{x)  is  a  value  for  all  x  G  dom(0).  We  use  e[9\  for 
the  result  of  applying  9  to  e  and  e[x\, . . . ,  xn  i— >  ei, . . . ,  en\  for  e[x\  >  e\, . . . ,  xn  i— ►  en\. 

Proposition  2.1.1  Given  a  value  form  u  and  an  expression  e,  u[x  i— ►  e]  is  also  a  value  form. 
Hence,  value  forms  are  closed  under  substitution. 

Proof  This  immediately  follows  from  a  structural  induction  on  u.  ■ 

Proposition  2.1.2  Given  values  v\  and  V2,  V2[x  t— >  tq]  is  also  a  value.  Hence,  values  are  closed 
under  value  substitution. 


Proof  This  immediately  follows  from  a  structural  induction  on  V2- 

•  V2  is  a  variable  y.  If  y  is  x,  then  V2[x  i— ►  tq]  =  v\  is  a  value.  Otherwise,  V2[x  t— >  rq]  =  y  is  also 
a  value. 

•  V2  is  of  form  A y.e.  Then  V2[x  t— >  tq]  =  A y.e[x  *— >  tq]  is  obviously  a  value.  Note  we  can  assume 
that  there  are  no  free  occurrences  of  y  in  tq. 

All  other  cases  can  be  readily  verified.  ■ 

Therefore,  a  significant  difference  between  value  forms  and  values  is  that  the  former  are  closed 
under  all  substitutions  while  the  latter  are  only  closed  under  value  substitutions.  This  is  the 
primary  reason  why  we  require  that  u  be  a  value  form  in  (fix  x.u ).  This  requirement  also  rules 
out  troublesome  expressions  such  as  (fix  x.x),  which  are  of  little  use  in  practice. 

2.1.1  Dynamic  Semantics 

We  will  present  the  operational  semantics  of  Apr  in  terms  of  natural  semantics  (Kahn  1987).  This 
approach  supports  a  short  and  clean  formulation,  but  it  prevents  us  from  distinguishing  a  “stuck” 
program  from  a  non-terminating  one.  An  alternative  would  be  using  the  “small-step”  reduction 
semantics,  which  does  enable  us  to  distinguish  a  “stuck”  program  from  a  non-terminating  one  but 
its  use  in  our  setting  is  more  involved.  We  feel  that  natural  semantics  suffices  for  our  purpose, 
and  therefore  choose  it  over  reduction  semantics.  Nonetheless,  we  will  formulate  the  reduction 
semantics  of  A^  when  studying  the  operational  equivalence  relation  in  A^. 

Given  a  pattern  p  and  a  value  v,  a  judgement  of  form  match(p,  v)  = =>■  9,  which  means  that 
matching  a  value  v  against  a  pattern  p  yields  a  substitution  for  the  variables  in  p,  can  be  derived 
with  the  application  of  the  rules  in  Figure  2.2.  Notice  that  the  rule  (match-prod)  makes  sense 
because  p\  and  p2  share  no  common  variables. 

The  natural  semantics  for  Ajvjt  is  given  in  Figure  2.3.  Notice  the  presence  of  the  rule  (ev-var), 
which  means  that  we  allow  the  evaluation  of  open  code,  that  is  code  containing  the  occurrences  of 
free  variables.  The  main  reason  is  that  we  hope  that  the  theorems  we  prove  are  also  applicable  to 
program  transformation,  where  the  manipulation  of  open  code  is  a  necessity. 

We  will  use  constants  0, 1,  — 1, . . .  for  integers  and  nil ,  cons  for  list  constructors  in  our  examples. 


Figure  2.3:  The  evaluation  rules  for  the  natural  semantics  of 
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Example  2.1.3  Let  V i  be  the  following  derivation. 

— - —  (ev-cons-wo)  - 

0  v  nil  ' 

(0,  nil )  c — >o  (0,  nil) 


0 


nil 


—  (ev-cons-wo) 
(ev-prod) 


co7is((0,nil))  c — >o  cons((0,nil)) 

Let  V 2  be  the  following  derivation. 

—  (match-var) 


match(:E,  0) 


0] 


matches,  nil)  =>  [ xs  i— >  nil ] 


match((a:,  xs),  (0 ,nil))  ==>  [ x  i— >  0,  xs  i— >  nil] 


(match-var) 
(match-prod) 
(match-cons-w) 


match(cons((0,TOl)),cons((a:,a;s)))  =4>  [x  >  0,  xs  i— >  nil] 

Let  tail  =  ALcase  l  of  cons((x,xs))  =>•  xs,  and  tail(cons({0,nil)))  nil  is  derivable  as  follows. 

—  (ev-cons-wo) 


tail 


tail 


—  (ev-lam) 


T>  i  V  2  nil 


nil 


V i  case  cons((0 ,  nil))  of  cons((x,  xs))  =>  xs  ^->o  nil 
tail(cons({0,nil)))  nil 


—  (ev-case) 


(ev-app) 


Notice  that  the  rule  (ev-case)  introduces  a  certain  amount  of  nondeterminism  into  the  dynamic 
semantics  of  APff  since  it  does  not  specify  which  matching  clause  is  chosen  if  several  are  applicable. 
On  the  other  hand,  it  is  specified  in  ML  that  pattern  matching  is  done  sequentially,  that  is,  the 
chosen  matching  clause  is  always  the  first  one  which  is  applicable.  However,  this  difference  is 
relatively  a  minor  issue  since  in  theory  we  can  always  require  that  all  matching  clauses  do  not 
overlap. 

Theorem  2.1.4  v  =—>0  v  for  every  value  v  in 


Proof  This  immediately  follows  from  a  structural  induction  on  v.  We  present  a  few  cases. 

•  v  =  (v\,V2).  By  induction  hypothesis  Vi  vi  are  derivable  for  i  =  1,2.  Hence  we  have  the 
following  derivation. 


v\  ^1  V2  ^0  V2 
v  c— >o  v 

v  =  lam  x.e.  Then  we  have  the  following. 


(ev-prod) 


V  ^0  V 


(ev-lam) 


All  other  cases  are  trivial.  ■ 

2.2  Mini-ML  with  Pattern  Matching 

We  now  introduce  an  explicitly  typed  programming  language  (MLo)  which  basically  extends  nrini- 
ML  (Clement,  Despeyroux,  Despeyroux,  and  Kahn  1986)  with  general  pattern  matching.  This 
is  a  simply  typed  version  of  A^.  The  syntax  of  MLo  is  given  in  Figure  2.4.  Given  a  context 
T  =  x'i  :  n, . . . ,  x  :  rn  (we  omit  the  leading  •  if  the  context  is  not  empty),  we  always  assume  that  all 
Xi  are  distinct  for  *  =  1, ... ,  n.  We  write  dom(r)  =  {aq, . . . ,  xn}  and  T(xj)  =  Tj  for  i  =  1, . . . ,  n. 
A  signature  declares  a  list  of  constructors  associated  with  their  types.  Notice  that  the  type  of  a 
constructor  is  required  to  be  of  form  either  f3  or  r  — >  /?,  where  f3  is  a  (user-defined)  base  type,  that 
is,  a  constructor  is  either  without  an  argument  or  with  exactly  one  argument. 
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base  types 

P  ■ 

:=  bool  int  (other  user  defined  datatypes) 

types 

T 

:=  /?  |  1  |  Ti  *  T2  I  Ti  — ►  72 

patterns 

p  : 

:=  x  |  c(jp)  |  <)  |  (pi,p2) 

matches 

ms 

:=  (p  =t  e)  |  (p  =t  e  ms) 

expressions 

e 

:=  x  |  ()  |  (ei,e2)  |  c(e)  |  (case  e  of  ms)  \  (lam  x  :  r.e)  |  ei(e2) 

let  x  =  ei  in  e 2  end  (fix  /  :  t.u) 

value  forms 

u 

:=  c(u)  ()  |  (ui,u2)  (lam  x  :  r.e) 

values 

v  : 

:=  x  |  c(v)  |  ()  |  {v\,v2)  |  (lam  x  :  r.e) 

contexts 

r  : 

:=  •  r,  x  :  r 

signatures 

5  : 

:=  •  |  5,  c  :  (3  |  5,  c  :  r  — ►  j3 

substitutions 

e  : 

:=  []  0[x  e] 

Figure  2.4:  The  syntax  for  MLq 


Figure  2.5:  The  typing  rules  for  patterns  in  MLq 


2.2.1  Static  Semantics 

Given  a  pattern  p  and  a  type  r,  we  can  derive  a  judgement  of  form  p  j  r  \>  T  with  the  rules  in 
Figure  2.5,  which  reads  that  checking  pattern  p  against  type  r  yields  a  context  F. 

In  the  following  examples,  we  assume  that  intlist  is  a  base  type  and  nil ,  cons  are  constructors 
of  type  intlist  and  int  *  intlist  — ►  intlist,  respectively. 


Example  2.2.1  The  following  is  a  derivation  of  cons ((x,  nil))  j  intlist  >  x  :  int. 


x  i  int  E>  x  :  int 


Slnil )  =  intlist 

(pat-var)  .  (pat-cons-wo) 


nil  i  intlist  D> 


S(cons)  =  int  *  intlist  — ►  intlist  ( x,nil }  j  int  *  intlist  >  x  :  int 

cons((x,nil })  j  intlist  >  x  :  int 


(pat-prod) 


(pat-cons-w) 


The  typing  rules  for  MLq  are  given  in  Figure  2.6.  We  present  an  example  of  type  inference  in 
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T(x)  =  r 
T  b  x  :  t 
S(c)  =  p 


(ty-var) 


T  b  c  :  p 
5(c)  =  t  — >  P  Their 


(ty-cons-wo) 


T  b  c(e)  :  5 


(ty-cons-w) 


Thp 


T  h  ()  :  1 
r  h  ei  :  n  r  h  e2  :  r2 
r  I-  (ei,e2)  :  ri  *  r2 
P[t\\>T'  r,r/he:r2 
rhp^e:ri^r2 
e  :  T\  =$■  t2  T  h  ms  :  ri 


(ty-unit) 

(ty-prod) 


(ty-match) 

=*>  t2 


F  I-  (p  =>•  e  |  ms)  :  T\  =>•  r2 
T  b  e  :  ri  T  h  ms  :  ti  =>•  r2 
T  b  (case  e  of  ms)  :  r2 
T,  x  :  Ti  b  e  :  r2 
T  b  (lam  x  :  T\  .e)  :  n  — ►  r2 
r  h  ei  :  n  — >  r2  f  h  e2  :  n 
T  h  ei(e2)  :  r2 

T  b  ei  :  ri  r,  x  :  n  b  e2  :  r2 


r  b  (let  x  =  ei  in  e2  end)  :  r2 

r,/:rl"ii:r 


(ty-matches) 
(ty-cases) 
(ty-lam) 
(ty-app) 
(ty-let) 


T  b  (fix  /  :  r.ti)  :  r 


(ty-fix) 


Figure  2.6:  The  typing  rules  for  MLq 


ML0. 

Example  2.2.2  The  following  is  a  derivation  of  ■  b  (lam  x  :  int . cons ((x,  nil)))  :  int  — >  intlist. 

S{nil)  =  intlist 


x  :  int  b  x  :  int  x  :  int  b  nil  :  intlist 


S(cons)  =  int  *  intlist  — >  intlist 


x  :  int  b  ( x,nil }  b  int  *  intlist 


(ty-cons-wo) 

(ty-prod) 


x  :  int  b  cons((x,nil))  :  intlist 
b  (lam  x  :  int . cons ({x,  nil)))  :  int  — ►  intlist 


(ty-cons-w) 


(ty-lam) 


Given  r,  T7  and  8,  a  judgement  of  form  T  b  9  :  T7  can  be  derived  with  the  application  of  the 
following  rules.  Such  a  judgement  means  that  dom(0)  =  dom(r/)  and  T  b  9(x)  :  r'(x)  is  derivable 
for  all  x  £  dom($). 

rFjjW  (subst-empty)  f.  (™bSt-var) 
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The  next  proposition  shows  that  judgement  T  b  9  :  T7  has  the  intended  meaning. 

Proposition  2.2.3  We  have  the  following. 

1.  IfT  b  6  :  T'  is  derivable,  then  dom($)  =  dom(T')  and  T  b  9(x)  :  T'(x)  is  derivable  for  every 
x  6  dom($). 


2.  Given  6 \  and  62  such  that  dom(0i)  fl  dom(#2)  =  0,  then  the  following  rule  is  admissible. 


TL01:T1  Th02:T2 
TL  9lU92:T1,T2 


(subst-subst) 


Proof  (1)  follows  from  a  structural  induction  on  the  derivation  of  T  b  9  :  P  and  (2)  follows  from 
a  structural  induction  on  the  derivation  of  T  b  92  :  T2-  We  present  the  proof  for  (2). 

•  $2  =  []•  This  is  trivial. 

•  92  =  9'2 [x  1— ►  e] .  Suppose  T2  =  r2,x  :  r.  Then  we  have  the  following  derivation. 

T  b  #2  :  T'2  f  h  x  :  t 


T  b  9'2 [x  1— i >  e]  :  T2 ,  x  :  t 


(subst-var) 


By  induction  hypothesis,  T  b  9\  U  9'-2  :  Ti,T2  is  derivable.  This  leads  to  the  following 
derivation. 

rh01u0'2:r1,r'2  rb*:r 

—7  -  ;  (subst-var) 

Th  (0lU9'2)[x^e]:rl,r,2,x:T  y  ’ 

Since  9\  U  92  is  ( 9\  U  9'2)[x  >  e]  and  p2  is  P2,  x  :  r,  we  are  done. 


Lemma  2.2.4  If  both  T,r'be:r  and  T  b  9  :  T'  are  derivable,  then  T  b  e[9]  :  r  is  derivable. 


Proof  The  proof  follows  from  a  structural  induction  on  the  derivation  V  of  r,Tr  b  e  :  r.  We 
present  a  few  cases. 

T(.x)  =  T 

V  = - 

r,T'  b  x  :  r  Then  x  0  dom(T').  Since  dom(0)  =  dom(T')  by  Proposition  2.2.3,  x  0 
dom(0).  This  implies  x[9]  =  x.  Clearly,  T  b  x  :  r  is  derivable. 


T,  P  b  x  :  t  Since  dom(0)  =  dom(T/)  by  Proposition  2.2.3,  x  €  dom($).  This  implies 
x[9\  =  9{x).  Note  T  b  9{x)  :  r  is  derivable  by  Proposition  2.2.3  since  T  b  9  :  T7  is. 


r,r‘ ,  X  :  Ti  b  ei  :  r2 
V  = - - 

r,  P'  b  (lam  x  :  ri.ei)  '■  T\  —>  t2  Then  we  can  derive  P,  x  :  r^T'  e\  :  r2  and  r,  x  : 

T\  b  9  :  T'.  By  induction  hypothesis,  T,x  :  t\  b  e\[9\  :  t2  is  derivable,  and  this  leads  to  the 
following  derivation. 


T, x  :  n  b  e\[9\  :  t2 
T  b  (Ax  :  T\.e\[0])  :  r2 


(ty-lam) 
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Figure  2.7:  Some  evaluation  rules  for  the  natural  semantics  of  MLq 


Note  x  0  dom(r')  =  dom($).  Since  T  b  9  :  T7,  x  0  F V(9(y))  for  all  y  G  dom(0).  Therefore, 
(Ax  :  T\.e\)[6\  =  Ax  :  ri.ei[0]. 

All  other  cases  can  be  handled  similarly.  ■ 

If  a  value  v  matches  a  pattern  p,  then  match(p,  v)  =>  9  is  derivable  for  some  substitution  9. 
The  next  lemma  shows  that  if  the  type  of  v  is  given,  then  the  type  of  9{x)  for  every  x  G  dom($) 
is  fixed.  This  is  crucial  to  proving  the  type  preservation  theorem  for  MLq. 


Lemma  2.2.5  If  V  b  v  :  r,  p  j  r  >  T'  and  match(p,  v)  =>  9  are  derivable,  then  T  9  :  T'  is 
derivable. 


Proof  By  a  structural  induction  on  the  derivation  T>  of  p  J,  r  t>  F7 .  We  present  one  case  as  follows. 

match(pi, ui)  9\  match(p2; ^2)  ^2 

T)  = - 

match((pi,p2),  {v\,V2))  =►  6\  U  9-2  By  induction  hypothesis,  T  h  9i  :  Tj  are 

derivable  for  i  =  1,2.  Hence  we  have  the  following  derivation  since  (subst-subst)  is  an 
admissible  rule  by  Proposition  2.2.3. 


Th91:T1  T  h  9-2  :  T2 
T\~  9iU92:T1,T2 


(subst-subst) 


All  other  cases  are  trivial. 


2.2.2  Dynamic  Semantics 

The  natural  semantics  of  MLo  is  almost  the  same  as  that  of  A^.  The  only  changes  are  made  in 
the  formulation  of  the  rules  in  Figure  2.7,  where  types  are  carried  around  during  evaluation.  All 
other  rules  are  unchanged. 

Notice  that  types  play  no  role  in  the  formulation  of  the  evaluation  rules  in  Figure  2.7.  To  make 
this  precise,  we  define  a  type  erasure  function  |  •  |  as  follows,  which  maps  an  expression  in  MLq  into 
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\x\  =  x 

|c|  =  c 

\p  =>  e\  =  p  =>  |e| 

\(p  =$■  e  \  ms) |  =  p  =>  |e|  |  |?ns| 

|case  e  of  ms|  =  case  |e|  of  |ms| 

|lam  x  :  r.e|  =  lam  x.|e| 

|ei(e2)|  =  |ei|(|e2|) 

let  x  =  ei  in  e2  end|  =  let  x  =  |ei|  in  |e2|  end 
|fix  /  :  t.u\  =  fix  /.|u| 

Theorem  2.2.6  Given  an  expression  e  in  MLo,  we  have  the  following. 

1.  If  e  >o  v  is  derivable  in  MLo,  then  |e|  M  is  derivable  in  Aj^. 

2.  if  |e|  ' — vo  is  derivable  in  A^\  then  e  ^->0  v  is  derivable  in  MLo  for  some  v  such  that 
M  =  v0. 

Proof  (1)  and  (2)  follow  from  a  structural  induction  on  the  derivations  of  e  ^->o  v  and  le|  H), 
respectively.  ■ 

Theorem  2.2.6  clearly  exhibits  the  indifference  of  types  to  evaluation.  However,  one  great  advantage 
of  imposing  a  type  system  on  a  language  is  that  we  are  then  able  to  prove  certainly  invariant 
properties  about  the  evaluation  of  well-typed  expressions. 

2.2.3  Soundness 

We  are  now  ready  to  present  the  type  preservation  theorem  for  MLo,  which  asserts  that  the  evalu¬ 
ation  rules  for  the  natural  semantics  of  MLo  does  not  alter  the  types  of  the  evaluated  expressions. 
Notice  that  this  theorem  is  closely  related  to  but  different  from  the  subject  reduction  theorem  (not 
presented  in  the  thesis),  which  asserts  that  the  (small-step)  reduction  semantics  of  MLo  is  type 
preserving. 

The  type  preservation  theorem  is  a  fundamental  theorem  which  relates  the  static  semantics  of 
MLo,  expressed  in  the  form  of  type  inference  rules,  to  the  dynamic  semantics  of  MLo,  expressed  in 
the  form  of  natural  semantics. 

Since  we  allow  the  evaluation  of  open  code,  the  formulation  of  the  following  type  preservation 
theorem  is  slightly  different  from  the  standard  one,  which  deals  with  only  closed  code  and  therefore 
needs  no  variable  context  to  keep  track  of  free  variables  in  the  code. 

Theorem  2.2.7  (Type  preservation  for  MLoJ  Given  e,v  where  e  c— >o  v  is  derivable.  7/T  h  e:  r  is 
derivable  then  T  b  v  :  r  is  also  derivable. 

Proof  This  follows  from  a  structural  induction  on  the  derivation  V  of  e  =—>0  v ■  We  present  a  few 
cases. 

V  = - 

x  c — >o  x  Trivially,  r  h  x  :  r  is  derivable  since  T  b  x  :  r  is  derivable. 
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eo  c— >o  vq  match(pfc,  vq)  ==>•  9  for  some  1  <  k  <  n  ek[9]  v 

(case  eo  of  (pi  =>  e\  \  ■  ■  ■  pn  =>  en))  v  Then  we  have  a  deriva¬ 

tion  of  the  following  form  since  T  b  (case  eo  of  (pi  =^>  e\  \  ■  ■  ■  \  pn  =^>  en))  :  r  is  derivable. 


r  b  e0  :  n  T  b  (pi  ei  |  •  •  •  |  pn  =>•  en)  :  n  =>  r 
r  b  (case  e0  of  (p1  =>  ei  |  •  •  •  |  =4-  en))  :  r 


(ty-case) 


By  induction  hypothesis,  T  b  vq  :  ri  is  derivable.  Notice  T  b  p*  e*  :  ri  =>  r  are  derivable 
for  1  <  i  <  n.  Hence  pk  |  ri  >  T7  is  derivable  for  some  H  and  r,r/  b  e^  :  r  is  derivable. 
By  Lemma  2.2.5,  T  b  6  :  T7  is  derivable.  This  leads  to  a  derivation  of  T  b  ek[9\  :  r  by 
Lemma  2.2.4.  By  induction  hypothesis,  T  b  v  :  r  is  derivable. 


e\  c — >0  (lam  x  :  n.e^)  e2  ^o  v2  e[[x  i-t  v2]  ^o  v 

ei(e2)  c— >o  v  Since  T  b  ei(e2)  :  r  is  derivable,  we 

have  a  derivation  of  the  following  form. 


T  b  e\  :  T\  —>  t  T  b  e2  :  n 
T  b  ei(e2)  :  r 


(ty-app) 


By  induction  hypothesis,  both  T  b  (Ax  :  ri.e^)  :  t\  — ■>  r  and  T  \-  v2  :  t\  are  derivable. 
Hence,  T  b  e\  [x  i— x2]  :  r  is  derivable  following  Lemma  2.2.4.  Again  by  induction  hypothesis, 
r  b  v  :  t  is  derivable. 

ei  ^o  vi  e2[x  ^  Vi]  v 
V  = - : - 

(let  x  =  e\  in  e2  end)  ^o  v  Since  T  b  let  x  =  e\  in  e2  end  :  r  is  derivable,  we  have 
a  derivation  of  the  following  form. 

r  b  ei  :  n  r,x:r1be2:r 

=n — r- ; - ; - ; -  (ty-let) 

i  b  let  x  =  e\  in  e2  end  :  r 

By  induction  hypothesis,  T  b  v\  :  ri  is  derivable.  Therefore,  T  b  e2[x  t)i]  :  r  is  derivable 
following  Lemma  2.2.4.  This  yields  that  T  b  v  :  r  is  derivable  by  induction  hypothesis. 


V  = - 

(fix  /  :  t.u )  c— >o  w[/  >  (fix  /  :  r.u)]  Since  T  b  (fix  /  :  t.u)  :  r  is  derivable,  we  have  a 

derivation  of  the  following  form. 


r,/:rb«:r 
T  b  (fix  /  :  t.u)  :  r 


(ty-fix) 


Hence,  T  b  u[f  i— ►  (fix  /  :  r.«)]  :  r  is  derivable  following  Lemma  2.2.4. 

All  other  cases  can  be  handled  similarly. 

Notice  that  in  the  case  where  e  is  let  x  =  ei  in  e2  end,  the  derivation  of  T  b  e2[x  i— >  xi]  :  r 
can  be  more  complex  that  that  of  T,  x  :  ti  b  e2  :  r.  Therefore,  the  proof  could  not  have  succeeded 
if  we  had  proceeded  by  a  structural  induction  on  the  derivation  of  f  b  e  :  r.  ■ 


26 


CHAPTER  2.  PRELIMINARIES 


2.3  Operational  Equivalence 

We  present  some  basics  on  operational  equivalence  in  this  section,  which  will  be  used  later  in 
Chapter  4  and  Chapter  5  to  prove  the  correctness  of  elaboration  algorithms.  This  is  also  an 
appropriate  place  for  us  to  mention  something  about  the  reduction  semantics  since  it  is  based  on 
the  notion  of  evaluation  context  that  we  introduce  as  follows. 

Definition  2.3.1  We  present  the  definition  of  evaluation  contexts  and  (general)  contexts  as  fol¬ 
lows. 

(evaluation  contexts)  E  ::=  []  |  (E,  e)  \  (v,E)  \  c(E)  |  case  E  of  ms 

|  E(e)  |  v(E)  |  let  x  =  E  in  e  end 

(match  contexts)  Cm  ::=  p  =3-  C  \  (p  =$■  e  \  Cm )  |  (p  =>  C  \  ms) 

(contexts)  C  ::=  []  |  (C,e)  \  (e,C)  \  c(C)  |  case  C  of  ms  |  case  e  of  Cm 

|  lam  x.(C)  |  C(e)  |  e(C) 

|  let  x  =  C  in  e  end  |  let  x  =  e  in  C  end  |  fix  f.C 

Given  a  context  C  and  an  expression  e,  C\e\  stands  for  the  expression  formulated  by  replacing 
with  e  the  hole  []  in  C.  We  emphasize  that  this  replacement  is  variable  capturing.  For  instance, 
given  C  =  lam  x.[],  then  C[x\  =  lam  x.x.  Given  two  contexts  C\  and  62,  C\[C?\  is  the  context 
formulated  by  replacing  with  C2  the  hole  []  in  C\ . 

Proposition  2.3.2  We  have  the  following. 

1.  Given  two  evaluation  contexts  E\  and  E2,  E\  [E2]  is  also  an  evaluation  context. 

2.  Given  an  evaluation  context  E  and  a  value  v,  E[x  *— >  u]  is  also  an  evaluation  context. 

3.  Given  an  evaluation  context  E  and  an  expression  e,  no  free  variables  in  e  are  captured  when 
the  hole  []  in  E  is  replaced  with  e. 

Proof  (1)  simply  follows  from  a  structural  induction  on  E\ .  We  present  a  few  cases. 

•  E\  =  [].  Then  E\  [E2]  =  E2  is  an  evaluation  context. 

•  E\  =  let  x  =  E[  in  e  end.  Then  E[  [E2]  is  an  evaluation  context  by  induction  hypothesis. 
Hence,  E\[Efi  =  let  x  =  E'fiEfi  in  e  end  is  also  an  evaluation  context 

•  E\  =  case  E[  of  ms.  Then  E[  [E2}  is  an  evaluation  context  by  induction  hypothesis.  Hence, 
Ei  [Efi  =  case  E\  [E2}  of  ms  is  also  an  evaluation  context 

The  rest  of  the  cases  can  be  handled  similarly. 

We  omit  the  proofs  of  (2)  and  (3),  which  are  based  on  a  structural  induction  on  E.  ■ 

Definition  2.3.3  We  define  as  follows  redexes  and  their  reductions  on  the  left-hand  and  right-hand 
sides  of  1— respectively. 

(lam  x.e)(v)  e- >  e[x  v\ 
let  x  =  v  in  e  end  1— ►  e[x  1— v\ 

fix  f.u  t— >  u[f  (fix  f.u)\ 
case  v  of  (Pl  =>  ei  \  ■  ■  ■  \  pn  =>  en)  ek[6\, 

where  match(u,pfc)  9  is  derivable  for  some  1  <  k  <  n 
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The  one-step  reduction  relation  i— ►  is  defined  as  follows.  e\  i— ►  e 2  if  and  only  if  e\  =  E[e]  for  some 
evaluation  context  E  and  redex  e  and  e2  =  E[e'],  where  e'  is  the  reduction  of  e.  We  also  say  e\ 
evaluates  to  e 2  in  one  step  if  e  1  t— >  e 2- 

Notice  that  the  relation  1— >  is  context-sensitive ,  that  is,  we  cannot  in  general  infer  C\e\  1— >•  C7[er] 
even  if  we  have  e  1— ►  e' .  However,  this  is  true  by  Proposition  2.3.2  if  C  is  an  evaluation  context. 
Let  1— P  be  the  reflexive  and  transitive  closure  of  1— ►.  The  reduction  semantics  of  Ajv"*  states  that  e 
evaluates  to  v  if  e  1— P  v  holds.  We  point  out  that  a  redex  of  form  case  v  of  ms  may  have  different 
reductions.  Therefore,  this  reduction  semantics  contains  a  certain  amount  of  nondeterminism. 

Clearly,  Proposition  2.3.2  implies  E[e\  1— P  E[e']  if  e  1— P  e! .  We  will  use  this  property  implicitly 
in  the  following  presentation.  The  next  theorem  relates  ^->0  and  e-P  to  each  other. 

Proposition  2.3.4  We  have  the  following. 

1.  If  e  is  not  a  value,  neither  is  E[e\. 

2.  If  e  =  E[r\  for  some  redex  r  and  e  =  E\[efi  for  some  e\  which  is  not  a  value,  then  ei  =  E-2[r\ 
for  some  E-2  and  E  =  E\  [E2] . 

3.  If  E\[ri]  =  E^j-2]  for  redexes  r\  and  r2,  then  E\  =  E2  and  r\  =  r2- 

4-  If  e  =  E[e  1]  1— P  v,  then  there  is  some  value  v\  such  that  e  =  E[e  1]  1— P  E[v  1]  1— P  v. 

Proof  (1)  simply  follows  from  the  definition  of  values.  We  now  proceed  to  prove  (2)  by  a 
structural  induction  on  E\ . 

•  E\  =  [].  Then  this  is  trivial. 

•  E\  =  (E[,e 2).  Then  e  =  (E[[e  1] , e2) -  Since  e\  is  not  a  value,  (1)  implies  that  £q[ei]  is  not  a 
value.  So  E  must  be  of  form  (E',e 2).  By  induction  hypothesis,  ei  =  E2 [r]  for  some  E2  such 
that  E'  =  E'1[E2\.  Note  E\[E2\  =  (E[[E2 ],e2)  =  (E',e 2)  =  E,  and  we  are  done. 

•  E\  =  (v,E[).  If  E  is  of  form  (E',e 2),  then  v  =  E'[r\.  Since  this  contradicts  (1),  E  must 
be  of  form  (v,E').  By  induction  hypothesis,  ei  =  E2 [r]  for  some  E2  such  that  E'  =  E[  [E2] 
Therefore,  E  =  E\  [E2],  and  this  concludes  the  case. 

The  rest  of  the  cases  can  be  treated  similarly.  (3)  and  (4)  immediately  follow  from  (2).  ■ 

Clearly,  Proposition  2.3.4  (3)  implies  that  if  e  can  be  reduced  then  there  exist  a  unique  evaluation 
context  E  and  a  redex  r  such  that  e  =  E [r] .  However,  r  may  have  different  reductions  if  r  is  of 
form  case  v  of  ms. 

Theorem  2.3.5  Given  an  expression  e  and  a  value  v  in  A^,  e  ^->0  v  if  and  only  if  e  *—>*  v 

Proof  We  write  ei  1— e2  to  mean  that  ei  evaluates  to  e2  in  n  steps.  Assume  e  1— v.  We 
prove  e  ^->0  v  by  an  induction  on  n  and  the  structure  of  e,  lexicographically  ordered.  We  do  a  case 
analysis  on  the  structure  of  e. 
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•  e  =  (ei,e2).  By  Proposition  2.3.4  (4),  there  exists  0  <  i,j  <  n  such  that  ei  i— d  v\  and 
e2  *— V2  for  some  v\  and  V2-  By  induction  hypothesis,  we  can  derive  e\  c— >o  v\  and  e2  ^2- 
This  yields  the  following. 


ei 


0  V\  e2  c  V2 
e^0v 


(ev-prod) 


•  e  =  ei(e2).  Then  there  exists  0  <  i,j  <  n  such  that  e\  i— d  v\  and  e2  i— ►  V2  for  some  v\  and 
V2,  where  v\  is  of  form  lam  x.e\ .  Hence  we  have  the  following. 

eH'.-n  (lam  x.e'1){v2)  i— ►  [x  t— >  V2}  e- >  ■  ■  ■  1— ►  v 


By  induction  hypothesis,  e\  ^->0  lam  x-e'\ ,  ^2  ^0  ^2  and  e\  [x  1— ► 
yields  the  following. 

ei  ^0  lam  x.e[  62^0^2  e'^x  v2]  ^0  v 

eM0» 


U2]  ^0  v  are  derivable.  This 

(ev-app) 


•  e  =  fix  f.u.  Then  e  1— >  u[f  1— ►  (fix  f.u)].  Clearly,  we  have  the  following. 

e  ^0  u[f  ^  (fix  f.u)]  ^GV  fiX^ 

All  other  cases  can  be  treated  similarly. 

We  now  assume  that  e  ^0  v  is  derivable  and  prove  e  1— A  v  by  a  structural  induction  on  the 
derivation  V  of  e  ^0  v ■  We  present  a  few  cases. 

ei  ^0  v\  &2  ^0  V2 
V  = - 

(ei,e2)  >0  (^1,^2)  By  induction  hypothesis,  We  have  e\  >*  v\  and  e2  e-C  V2-  This 

yields  the  following  since  both  ( [] , €2 )  and  (vi,  []}  are  evaluation  contexts. 

e  =  (ei,  e2)  (Vl,  e2)  (vi,v2) 

eo  ^->0  vo  match(uo,Pfc)  =>■  0  for  some  1  <  k  <  n  ek[0 \  ^->0  v 

(case  eo  of  (pi  ei  |  •  •  •  |  pn  =>•  en))  c— >0  v  By  induction  hypothesis, 

we  have  eo  >— >*  vo  and  ek[0\  1— >*  v.  This  leads  to  the  following. 

case  eo  of  (pi  =>•  ei  |  •  •  •  |  pn  =$■  en)  1— ►*  case  vq  of  {jp\  =>•  ei  |  •  •  •  |  pn  =$■  en)  *— >  ek[0]  i— C  v 


e\  c— >0  (lam  x.e\ )  e2  ^0  V2  e\  [x  >->  U2]  ^0  v 

V  = - - - - - — - - - 

ei(e2)  ^0  v  By  induction  hypothesis,  we  have  e\  1— ►* 

(lam  x.e'i),  e2  >— d  V2  and  e\  [x  1— >  V2]  1— d  v.  This  leads  to  the  following. 

e  =  ei(e2)  e-d  (lam  x.e'1)(e2)  e-d  (lam  x.ei)(v2)  1— >  e'][x  1— ►  ^0  v 

All  other  cases  can  be  treated  similarly.  ■ 

We  will  present  elaboration  algorithms  in  Chapter  4  and  Chapter  5,  which  map  a  program 
written  in  an  external  language  into  one  in  an  internal  language.  We  will  have  to  show  that  the 
elaboration  of  a  program  preserves  its  operational  semantics.  For  this  purpose,  we  introduce  the 
notion  of  operational  equivalence  in  . 
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Definition  2.3.6  Given  two  expression  e\  and  in  ,  e\  is  operationally  equivalent  to  e 2  if 
the  following  holds. 

•  Given  any  context  C,  C[e  1]  1— ►*  ()  is  derivable  if  and  only  if  C[e 2]  1— >*  (}  is. 

We  write  e\  =  e 2  if  e \  is  operationally  equivalent  to  62- 

Clearly  =  is  an  equivalence  relation.  Our  aim  is  to  show  that  let  x  =  e  in  E\x\  end  is  operationally 
equivalent  to  E\e]  for  any  evaluation  context  E  containing  no  free  occurrences  of  x.  However,  this 
seemingly  easy  task  turns  out  to  be  tricky.  We  will  explain  the  need  for  the  following  definition  in 
the  proof  of  Lemma  2.3.11. 

Definition  2.3.7  The  extended  values  and  extended  evaluation  contexts  are  defined  as  follows. 

(extended  values)  w  :=  x  \  c(w )  |  ()  |  (w\,W2)  |  (lam  x.e)  |  (fix  f.u) 

(extended  evaluation  contexts)  F  :=  []  |  (F,  e)  \  ( w,F )  \  c(F)  |  case  F  of  ms 

|  F(e)  |  w(F)  |  let  x  =  F  in  e  end 

ei  e2  if  e  1  =  F[e]  for  some  F  and  redex  e  and  e 2  =  F[e'],  where  e'  is  the  reduction  of  e.  Let 
h- >*F  be  the  reflexive  and  transitive  closure  of*-->F. 

Clearly,  the  difference  between  extended  values  and  values  is  that  expression  of  form  fix  f.u  belongs 
the  former  but  not  latter.  Informally  speaking,  it  allows  us  to  treat  an  expression  of  form  fix  f.u 
as  a  value  when  an  extended  evaluation  context  is  formulated.  However,  fix  f.u  should  not  be 
regarded  as  a  value  when  a  redex  is  formulated.  For  instance,  (lam  x.x)(fix  f.u )  is  not  a  redex. 

Unlike  the  evaluation  contexts,  the  extended  evaluation  contexts  do  not  enjoy  Proposition  2.3.4 
(3).  For  instance,  given  e  =  Fix(I(I)),  where  Fix  =  fix  /.lam  x.f(x)  and  /  =  (lam  x.x ),  e  can 
be  reduced  in  one  step  to  (lam  x.Fix(x))(I(I))  or  to  (fix  /.lam  x.f(x))(I).  The  next  proposition 
states  some  relation  between  values  (evaluation  contexts)  and  extended  values  (extended  evaluation 
contexts). 

Proposition  2.3.8  We  have  the  following. 

1.  Given  any  extended  value  w,  w  1— v  for  some  value  v. 

2.  Given  any  extended  evaluation  context  F  and  expression  e,  F[e\  t— >*  E[e\  for  some  evaluation 
context  E,  where  E  is  determined  by  F. 

Proof  (1)  follows  from  a  structural  induction  on  w.  We  present  an  interesting  case. 

•  re  is  of  form  fix  f.u.  Then  w  ^  u[f  1— >  w\.  Since  u[f  1— >  w]  is  a  value,  we  are  done. 

We  prove  (2)  by  a  structural  induction  on  F.  Here  are  a  few  cases. 

•  F  is  of  form  w(Fi).  Then  by  induction  hypothesis  F\[e\  E\[e\  for  some  E±.  By  (1), 

w  e- P  v  for  some  v.  Hence,  we  have 

F[e]  =  rc(Fi[e])  e- U  u(Fi[e])  1— >*  v(Ei[e\)  =  E[e] 


for  E  =  v(Ei). 
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•  F  is  of  form  let  x  =  F\  in  e\  end.  By  induction  hypothesis,  -Fife]  t— >*  Fife]  for  some  E\ . 
Hence,  we  have 

F[e]  =  let  x  =  Fife]  in  e\  end  h-F  let  x  =  Fife]  in  ei  end  =  Ffe] 
for  F  =  let  x  =  E\  in  ei  end. 

All  other  cases  can  be  treated  similarly.  ■ 

We  now  relate  t-*p  to  i— >.  Clearly,  ei  >  e2  implies  ei  i— >f  02  since  an  evaluation  context  is  an 
extended  evaluation  context.  In  the  other  direction,  we  have  the  following. 

Lemma  2.3.9  Given  an  expression  e  and  a  value  v  in  A^ ,  if  e  >*F  v  then  e  t— >*  v. 

Proof  Assume  e  v  and  we  proceed  by  an  induction  on  n.  If  n  =  0  then  it  is  trivial. 
Assume  e  =  Ffei]  i— >f  Ffei]  v  for  some  F,  where  ei  is  a  redex  and  e]  is  its  reduction.  By 
induction  hypothesis,  Ffe]]  t— P  v.  Note  that  Ffei]  i— >*  Ffei]  and  F[e]J  i— >*  Ffe]]  for  some  F  by 
Proposition  2.3.8  (2).  This  leads  to 

e  =  Ffei]  •— 1 ►*  Ffei]  ►  F[e]J  i— >*  v 


Therefore,  the  operational  semantics  of  A(W  is  not  affected  even  if  we  treat  expressions  of  form 
fix  f.u  as  values  when  formulating  evaluation  contexts. 

Definition  2.3.10  A  flp-redex  r  is  an  expression  of  form  let  x  =  e  in  Ffx]  end,  where  there  are 
no  free  occurrences  of  x  in  F.  e\  —>pF  e 2  if  e  1  is  of  form  C[r ]  for  some  (3p-redex  r  =  let  x  = 
e  in  Ffx]  end  and  e 2  =  CfFfe]].  We  write  —+*gF  for  the  reflexive  and  transitive  closure  of  ~^gF 

Lemma  2.3.11  Suppose  ei  — s >gF  e2-  We  have  the  following. 

1.  If  ei  1— >f  e'l,  then  for  some  e'2,  e2  e2  and  e]  ~^*gF  e2;  where  e2  e2  means  either 

e-2  =  e2  or  e2^>F  e2 . 

2.  If  e 2  *-^f  e2,  then  either  ei  wj?  e2  or  for  some  e] ,  ei  *-^f  e'\  and  e 1  -^*gF  e2. 

Proof  For  (1),  we  proceed  by  a  structural  induction  on  ei. 

•  ei  is  of  form  (fix  f.u\).  Then  e2  =  (fix  f.u2)  for  some  u2  such  that  u\  ~^gF  u2.  Note 
e]  =  uflf  1— >  ei] .  Let  e2  =  U2[f  |— ►  62],  then  e2  ^f  e2.  If  r  is  a  ftp- redex  in  u±,  then  we 
observe  that  r[f  1— ►  ei]  is  a  /I/?- redex  in  e] .  This  is  exactly  the  case  which  would  not  go 
through  if  we  had  not  defined  the  notion  of  extended  evaluation  context. 

With  this  observation,  it  is  not  difficult  to  see  that  e]  — e2. 

All  other  cases  can  be  handled  similarly. 

For  (2),  we  also  proceed  by  a  structural  induction  on  e\. 

•  ei  =  let  x  =  w  in  Ffx]  end.  Then  there  are  several  subcases. 
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—  ei  — >/3f  let  x  =  w'  in  F\x]  end  =  e2,  where  w  —>pF  w' .  We  have  e\  F\w\  —>pF 

F[w']  and  e2  *—>f  F[w'].  So  e2  =  F[w'].  Let  e\  =  F[w],  and  we  are  done. 

—  ei  — >pF  F[w]  =  e2.  Then  e\  t-^F  e2. 

—  e\  —>0F  let  x  =  w  in  F'[ x\  end  =  e2,  where  F[x\  —*pF  F'[x\.  We  have  e\  *->f  F[w]  — >pF 
F'[w\  and  e2  i— >F  F'[w\.  So  e'2  =  F'[w].  Let  e\  =  F[w]  and  we  are  done. 

All  other  cases  can  be  treated  similarly.  ■ 

Lemma  2.3.12  Let  e\  and  e2  be  two  expressions  in  such  that  e\  e2.  We  have  the 

following. 

1.  If  ei  t-^F  v\  for  some  value  v\,  then  e2  i— >*F  w2  for  some  value  V2  such  that  v\  —>*pF  V2- 

2.  //e2  t—>*F  V2  for  some  value  v2;  then  e\  >*F  v\  for  some  value  v\  such  that  v\ 

Proof  Assume  e\  i— Af?  v\.  We  prove  (1)  by  induction  on  n. 

1.  n  =  0.  Then  this  is  trivial. 

2.  n  >  0.  Then  e±  e^-F  i— >*F  v\  for  some  e^.  Then  by  Proposition  2.3.11  (1),  there  exists  e2 

such  that  e2  e2  and  e^  —>gF  e2.  By  induction  hypothesis,  e2  e^*F  u2  for  some  value  u2 

such  that  vi 

Assume  e2  e^rF  u2.  We  now  prove  (2)  by  induction  on  n. 

1.  n  =  0.  Then  e±  —>™F  e2  =  u2  for  some  m.  It  is  straightforward  to  prove  that  e\  ^*F  v\  for 
some  v\  such  that  v\  **0F  v2  by  induction  on  m. 

2.  n  >  0.  Then  e2  <-^-F  e2  i— >*F  u2  for  some  e2.  Then  by  Proposition  2.3.11  (2),  we  have  two 
cases. 

•  ei  e2.  Then  ei  e^*F  u2.  Hence,  let  v\  =  u2  and  we  are  done. 

•  ei  c^f  o'\  for  some  e\  such  that  e!x  ~^*pF  e2-  By  induction  hypothesis,  e'i  i— >*F  v\  for  some 
value  v\  such  that  v\  y2- 

Therefore,  both  (1)  and  (2)  hold.  ■ 

Corollary  2.3.13  For  every  extended  evaluation  context  F  and  every  expression  e  in  A]^ , 

let  x  =  e  in  F[x]  end  =  F[e] 
holds  if  x  has  no  occurrences  in  F. 

Proof  Notice  let  x  =  e  in  F[x\  end  is  a  /3F- redex.  Hence,  we  have 

C[let  x  =  e  in  F[x]  end]  -hF  C[F[e]]. 

Suppose  C[let  x  =  e  in  F[x\  end]  i— >*  (}.  Then  C[P[e]]  i— ►  v  follows  from  Proposition  2.3.12 
(1)  such  that  ()  e- P  v.  Hence  v  =  (). 
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Suppose  C[.F[e]]  i— >*  (}.  Then  C[let  x  =  e  in  F\x\  end]  i— ►  v  follows  from  Proposition  2.3.12 
(2)  such  that  v  i— A  (}.  This  implies  v  =  (}  since  v  is  a  value. 

Therefore,  let  x  =  e  in  Tf.x]  end  =  T[e]  by  the  definition  of  operational  equivalence.  ■ 

Since  an  evaluation  context  is  an  extended  evaluation  context,  we  have  derive  the  following 
operational  equivalence  for  every  evaluation  context  E  in  which  there  are  no  occurrences  of  x. 

let  x  =  e  in  E[x\  end  =  E[e] 

This  equivalence  will  still  hold  after  we  extend  the  language  with  effects  such  as  references  and 
exceptions,  although  we  will  no  longer  present  a  proof. 

Lastly,  we  list  some  properties  which  can  be  proven  similarly. 

Proposition  2.3.14  we  have  the  following. 

1.  (lam  x.(lam  y.e)(x))  =  (lam  y.e). 

2.  (fix  f.u)  =*  u[f  ^  (fix  f.u)]. 

3.  let  x  =  w  in  e  end  =  e\x  i— ►  w\ . 

The  need  for  introducing  extended  values  and  extended  evaluation  contexts  stems  from  the 
adoption  of  the  rule  (ev-fix)  in  which  the  non-value  (fix  f.u)  is  substituted  for  a  variable  /,  which 
is  regarded  as  a  value.  We  now  suggest  two  non-standard  alternatives  to  coping  with  this  problem. 

1.  The  first  alternative  is  that  we  classify  variables  into  two  categories.  One  category  contains 
the  variables  which  are  regarded  as  values  and  the  other  category  contains  the  variables  which 
are  not  regarded  as  values.  The  variables  bound  by  lam  must  be  in  the  first  category  and  the 
variables  bound  by  fix  must  belong  to  the  second  one.  This  avoids  substituting  non- values 
for  variables  which  are  regarded  as  values. 

2.  The  second  alternative  is  to  replace  the  rule  (ev-fix)  with  the  following  evaluation  rules. 
This  readily  guarantees  that  only  values  can  be  substituted  for  variables. 

(fix  f.u)  c  >o  u[f  ^  u*] 

where  u*  =  u[f  i— >  (fix  f.u)].  This  strategy  is  clearly  justified  by  Proposition  2.3.14  (2). 

2.4  Summary 

We  started  with  A^ ,  a  untyped  A-calculus  with  general  pattern  matching.  The  importance  of 
Av(d  lies  in  ^s  operational  semantics,  which  is  given  in  the  style  of  natural  semantics.  We  then 
introduced  MLo,  the  typed  version  of  A^ .  An  important  observation  at  this  point  is  that  types 
play  no  role  in  program  evaluation.  As  we  shall  see,  this  property  will  be  kept  valid  in  all  the  typed 
languages  that  we  introduce  later  in  this  thesis. 

However,  we  emphasize  that  recent  studies  (Tarditi,  Morrisett,  Cheng,  Stone,  Harper,  and  Lee 
1996;  Morrisett,  Walker,  Crary,  and  Glew  1998)  have  convincingly  shown  that  the  use  of  types  can 
be  very  helpful  for  detecting  errors  in  compiler  writing  and  enhance  the  performance  of  compiled 
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code.  We  will  actually  demonstrate  in  Chapter  9  that  dependent  types  can  indeed  lead  to  more 
efficient  code. 

In  addition,  we  studied  the  operation  equivalence  relation  in  which  will  be  used  later  to 
prove  the  correctness  of  some  type-checking  algorithms.  We  are  now  ready  to  introduce  dependent 
types  into  MLq. 
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Chapter  3 

Constraint  Domains 


Our  enriched  language  will  be  parameterized  over  a  constraint  domain,  from  which  the  type  index 
objects  are  drawn.  Typical  examples  of  constraints  include  linear  equalities  and  inequalities  over 
integers,  equations  over  the  algebraic  terms  (also  called  the  Herbrand  domain),  first-order  logic 
formulas  over  a  finite  domain,  etc.  Much  of  the  work  in  this  chapter  is  inspired  and  closely  related 
to  the  CLP  (Constraint  Logic  Programming)  languages  presented  in  (Jaffar  and  Maher  1994). 


3.1  The  General  Constraint  Language 


We  emphasize  that  the  general  constraint  language  itself  is  typed.  In  order  to  avoid  potential 
confusion  we  call  the  types  in  the  constraint  language  index  sorts.  We  use  b  for  base  index  sorts 
such  as  o  for  propositions  and  int  for  integers.  A  signature  E  declares  a  set  of  function  symbols 
and  associates  with  every  function  symbol  an  index  sort  defined  below.  A  Yi-structure  V  consists 
of  a  set  dom(T>)  and  an  assignment  of  functions  to  the  function  symbols  in  E. 

We  use  f  for  interpreted  function  symbols,  p  for  atomic  predicates  (that  is,  functions  of  sort 
7  — ►  o)  and  we  assume  we  have  constants  such  as  equality,  truth  values  T  and  _L,  conjunction  A, 
and  disjunction  V,  all  of  which  are  interpreted  as  usual. 

index  sorts  7  ::=  b  |  1  |  71  *  72  |  {a  :  7  \P} 

index  propositions  P  ::=  T  |  T  |  p(i)  \  P\  A  P2  \  Pi  V  P2 


Here  {0:7!  P}  is  the  subset  index  sort  for  those  elements  of  index  sort  7  satisfying  proposition 
P,  where  P  is  an  index  proposition.  For  instance,  nat  is  an  abbreviation  for  {a  :  int  \  a  >  0},  that 
is,  nat  is  a  subset  index  sort  of  int. 

We  use  a  for  index  variables  in  the  following  formulation.  We  assume  that  there  exists  a 
predicate  =  of  sort  7  *  7  — >•  o  for  every  index  sort  7,  which  is  interpreted  as  equality.  Also  we 
emphasize  that  all  function  symbols  declared  in  E  must  be  associated  with  index  sorts  of  form 
7  — >  b  or  b.  In  other  words,  the  constraint  language  is  first-order. 


index  objects 

A  .7 

::=  a  |  f (i) 

index  contexts 

0 

::=  -\<t>,a 

index  constraints 

$ 

■■=  i  =  j  1 

index  substitutions 

9 

::=  []|% 

satisfiability  relation 

<t>\=$ 

I  0  I  (i,j)  I  fstW  I  sndW 

:  7  I  <t>,P 

T  |  $1  A  d>2  |  P  A  |  Va  :  7.$  |  3a  :  7.$ 


35 


36 


CHAPTER  3.  CONSTRAINT  DOMAINS 


An  index  variable  can  be  declared  at  most  once  in  an  index  context.  The  domain  of  an  index 
context  is  defined  as  follows. 


dom(-)  =  0  dom(0,  a  :  7)  =  dom(0)  U  {a}  dom(^>,  P )  =  dom(^) 


Also  <f(a )  =  7  for  every  a  £  dom(</>)  if  a  :  7  is  declared  in  </>.  A  judgement  of  the  form  cf  b  9  :  <f>' 
can  be  derived  with  the  use  of  the  following  rules. 


—  -  (subst-iempty) 

$  []  :  •  ' 


cj)\-  0  :  (j)r  (f>\-  i  :  j 
4>  h  9[a  1— >  i]  :  f> ,  a  :  7 
<j)h  6:  ft  <j)\=  P[9] 


<j>\-  9  :  <fJ,P 


(subst-ivar) 

(subst-prop) 


Proposition  3.1.1  If  f  b  9  :  <jj  is  derivable,  then  dom(0)  =  dom(0/)  and  <fi  h  9(a)  :  <f' (a )  is 
derivable  for  every  a  £  dom(0). 

Proof  This  simply  follows  from  a  structural  induction  on  the  derivation  of  f  h  9  :  (j)' ,  parallel  to 
that  of  Proposition  2.2.3.  ■ 

We  present  the  sort  formation  and  sorting  rules  for  type  index  objects  in  Figure  3.1.  We  explain 
the  meanings  of  these  judgements  as  follows.  A  judgement  of  form  h  </>[ictx]  means  that  f  is  a 
valid  index  context,  and  a  judgement  of  form  <f  h  7  :  means  that  7  is  a  valid  sort  under  </>,  and 
a  judgement  of  form  f  \~  i  :  7  means  that  i  is  of  sort  7  under  cf.  Since  the  constraint  language  is 
explicitly  sorted,  sort-checking  can  be  done  straightforwardly  following  the  presented  sorting  rules. 
Details  on  sort-checking,  which  involves  constraint  satisfaction,  can  be  found  in  Subsection  4.2.6. 

We  could  certainly  allow  any  first-order  logic  formula  to  be  a  constraint.  However,  in  practice, 
we  often  consider  a  subset  of  formulas  closed  under  the  above  definition  to  be  constraints.  We  use 
C  for  a  class  of  S-formulas  (constraints),  and  we  call  the  pair  (V,C)  a  constraint  domain,  where 
V  is  a  E-structure.  Sometimes,  we  simply  use  C  for  a  constraint  domain. 

We  define  (0)$  as  follows. 

(.)$  =  $ 

(a  :  &)$  =  Va  :  6.<h 

(a:  71  *  72)$  =  (ai  :  7i)(a2  :  72)<h[a  ^  (ai,  a2)] 

(<M«  :  7  I  ^})$  =  (<(>)(«:  7)0P  D  $) 

(cf,  P) $  =  («/>)  (PD$) 

We  say  that  (j>  \=  $  is  satisfiable  in  C  =  (D,T)  if  (0)<h  is  true  in  V  in  the  model-theoretic  sense, 
that  is,  the  interpretation  of  (0)$  in  T>  is  true. 

We  also  present  some  basic  rules  for  reasoning  about  the  satisfiability  of  <f>  \=  $  as  follows.  Note 
that  there  also  exist  other  rules  such  as  induction  and  model  checking,  which  are  associated  with 
certain  special  constraint  domains. 
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Figure  3.1:  The  sort  formation  and  sorting  rules  for  type  index  objects 
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Clearly,  these  rules  are  not  enough.  We  have  to  be  able  to  verify  the  derivability  of  a  satisfiability 
relation  of  form  c[>  |=  P.  We  say  that  (j)  |=  P  is  derivable  in  a  constraint  domain  C  =  (D,T)  if  (4>)P 
is  satisfiable  in  dom(P).  In  order  to  verify  whether  {<f)P  is  satisfiable  in  V,  one  may  use  some 
special  methods  associated  with  C  such  as  model-checking  for  finite  domains.  We  can  readily  prove 
that  (</>)<h  is  satisfiable  if  c[>  \=  <!>  is  derivable.  This  establishes  the  soundness  of  this  approach  to 
solving  constraints.  Clearly,  this  may  not  be  a  complete  approach.  For  instance,  even  if  3a  :  7.<h  is 
satisfiable  in  dom(H),  there  may  not  exist  an  index  i  expressible  in  the  constraint  language  such 
that  <h[a  i— >  i]  is  satisfiable.  Also,  the  special  methods  employed  to  verify  the  the  satisfiability  of 
(( p)P  may  not  be  complete. 

Proposition  3.1.2  We  have  the  following. 

1.  If  both  <f>\=  P  and  <j>,  P  |=  $  are  derivable,  then  <f\  =  $  is  derivable. 

2.  If  both  (j)  h  i  :  7  and  (j>,a  :  7  |=  $  are  derivable,  then  4>  \=  <h[a  1— >•  ?']  is  also  derivable. 

3.  If  both  (j)  h  9  :  <$  and  (j>,  <f>'  (=  $  are  derivable,  then  f  \=  <!>[#]  is  also  derivable. 

Proof  All  these  are  straightforward.  ■ 

Note  that  the  rule  (sat-exists)  is  not  syntax-directed.  This  could  be  a  serious  problem  which 
hinders  the  efficiency  of  a  constraint  solver.  In  Subsection  4.2.6,  we  will  introduce  a  procedure 
which  eliminates  existential  variables  in  the  constraints  generated  during  type-checking.  In  the 
prototype  implementation,  we  simply  reject  a  constraint  if  some  existential  quantifiers  in  it  cannot 
be  eliminated.  The  practical  significance  of  this  decision  is  to  make  constraint  solving  as  feasible 
as  possible  for  typical  use.  Another  important  reason  is  that  this  can  significantly  help  generate 
comprehensible  error  messages  as  our  experience  indicates. 

Not  much  of  our  development  depends  on  the  precise  form  of  the  constraint  domain,  except 
that  the  constructs  above  must  be  present  in  order  to  reduce  dependent  type-checking  to  constraint 
satisfaction.  For  example,  implication  P  D  $  is  necessary  to  express  constraints  arising  from 
pattern  matching.  Though  subset  sorts  {0:7)  P}  are  not  strictly  required  in  the  formulation  of 
the  type  system,  they  are  crucial  to  making  the  system  expressive  enough  for  practical  use. 

3.2  A  Constraint  Domain  over  Algebraic  Terms 

We  present  a  constraint  domain  over  algebraic  terms.  In  the  signature  Eaig  of  this  domain,  a 
declaration  is  of  form  /  :  b\  *  •  •  •  *  bn  —>  b.  If  it  is  preferred  to  have  an  unsorted  constraint  domain, 
then  one  can  assume  that  there  is  only  one  base  sort  term,  which  stands  for  the  sort  of  all  terms. 

Let  us  present  an  interesting  example,  in  which  the  type  index  objects  are  drawn  from  Saig. 
We  use  the  following  datatype  to  represent  pure  untyped  lambda-terms  in  de  Bruijn’s  notation. 
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Figure  3.2:  The  rules  for  satisfiability  verification 


datatype  lambda_term  =  One  |  Shift  of  lambda_term  I 

Abs  of  lambda_term  | 

App  of  lambda_term  *  lambda_term 


Suppose  that  there  is  a  base  sort  level,  and  the  following  function  symbols  are  declared  in  £aig. 

zero  :  level  and  next  :  level  — ►  level 


This  enables  us  to  refine  the  datatype  lambda_term  into  the  following  dependent  type. 


typeref  lambda_term  of  level 

with  One  <|  {1: level}  lambda_term(next (1) ) 

I  Shift  <|  {1: level}  lambda_term(l)  ->  lambda_term(next (1) ) 

I  Abs  <|  {1: level}  lambda_term(next (1) )  ->  lambda_term(l) 

I  App  <|  {1: level}  lambda_term(l)  *  lambda_term(l)  ->  lambda_term(l) 

Roughly  speaking,  if  the  de  Bruijn’s  notation  of  a  A-term  is  of  type  lambda_term(l) ,  where 
l  =  next( ■  ■  ■  (zero)  ■  ■  •)  contains  n  occurrences  of  next,  then  there  are  at  most  n  free  variables  in 
the  A-term.  Therefore,  the  type  of  all  closed  A-terms  is  lambda_term(zero) . 

This  is  a  very  simple  constraint  domain.  Given  (j>  and  P,  the  rules  in  Figure  3.2  can  be  used 
verify  if  (4>)P  is  satisfiable.  Notice  that  </>o  and  (j)p  are  index  contexts  of  forms  a\  :  b\, ...  ,an  :  bn 
and  Pi, ... ,  Pn,  respectively.  We  say  that  (4>)P  is  satisfiable  if  •  )=[•]  (4>)P  is  derivable.  It  is  clear 
that  Eaig  should  not  to  be  fixed  so  that  the  programmer  can  then  be  allowed  to  declare  the  sorts  of 
function  symbols.  The  simple  reason  for  this  is  that  the  rules  for  satisfiability  verification  in  this 
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domain  are  not  effected  by  such  declarations.  The  following  is  a  sample  derivation. 


•  |=[a  :  level,  b  :  level]  b  =  b 
a  =  b  |=[a  :  level,  b  :  level]  a  =  b 
next(a)  =  next(b )  | =[a  :  level,  b  :  level]  a  =  b 
■  |=[a  :  level,  b  :  level]  next(a)  =  next{b )  D  a  =  b 
•  |=[a  :  level]  V(6  :  level). next(a)  =  next{b )  D  a  =  b 
•  ]=[•]  V(a  :  level)M(b  :  level)  .next(a)  =  next{b)  D  a  =  b 

Lastly,  we  remark  that  if  disequations  are  allowed  in  this  constraint  domain  then  the  rules  for 
satisfiability  verification  can  be  extended  straightforwardly. 


3.3  A  Constraint  Domain  over  Integers 

We  present  an  integer  constraint  domain  in  this  section.  The  signature  of  the  domain  is  given 
in  Figure  3.3.  We  also  list  some  sample  constraints  in  Figure  3.4,  which  are  generated  during 
type-checking  the  binary  search  program  in  Figure  1.3. 

Unfortunately,  there  exist  no  practical  constraint  solving  algorithms  for  this  constraint  domain 
in  its  full  generality.  This  poses  a  very  serious  problem  since  our  objective  is  to  design  a  depen¬ 
dent  type  system  for  general  purpose  practical  programming.  In  Subsection  4.2.6,  a  procedure 
is  introduced  to  eliminate  existential  quantifiers  in  constraints  generated  during  type-checking. 
We  currently  simply  reject  a  constraint  if  some  existential  quantifiers  in  it  cannot  be  eliminated. 
Therefore,  the  constraints  which  are  finally  passed  to  a  constraint  solver  consist  of  only  linear 
inequalities,  for  which  there  exist  practical  solvers. 

3.3.1  A  Constraint  Solver  for  Linear  Inequalities 

When  all  existential  variables  have  been  eliminated  (Subsection  4.2.6)  and  the  resulting  constraints 
collected,  we  check  them  for  linearity.  We  currently  reject  non-linear  constraints  rather  than 
postponing  them  as  hard  constraints  (Michaylov  1992),  which  is  planned  for  future  work.  If  the 
constraints  are  linear,  we  negate  them  and  test  for  unsatisfiability.  Our  technique  for  solving  linear 
constraints  is  mainly  based  on  Fourier-Motzkin  variable  elimination  (Dantzig  and  Eaves  1973),  but 
there  are  many  other  methods  available  for  this  purpose  such  as  the  SUP-INF  method  (Shostak 
1977)  and  the  well-known  simplex  method.  We  have  chosen  Fourier-Motzkin ’s  method  mainly  for 
its  simplicity. 

We  now  briefly  explain  this  method.  We  use  x  for  integer  variables,  a  for  integers,  and  l  for 
linear  expressions.  Given  a  set  of  inequalities  S,  we  would  like  to  show  that  S  is  unsatisfiable.  We 
fix  a  variable  x  and  transform  all  the  linear  inequalities  into  one  of  the  forms  l  <  ax  or  ax  <  l 
for  a  >  0.  For  every  pair  l\  <  a±x  and  a^x  <  1-2,  where  a\,a2  >  0,  we  introduce  a  new  inequality 
a2 h  <  a\l2  into  S,  and  then  remove  from  S  all  the  inequalities  involving  x.  Clearly,  this  is  a  sound 
but  incomplete  procedure.  If  x  were  a  real  variable,  then  the  elimination  would  also  be  complete. 

In  order  to  handle  modular  arithmetic,  we  also  perform  another  operation  to  rule  out  non¬ 
integer  solutions:  we  transform  an  inequality  of  form 


aixi  ■  -(-  aYiXrn  Si  u 
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Sint  —  abs 

int  — >  int 

sgn 

int  —>  int 

succ 

int  —>  int 

pred 

int  —>  int 

int  —>  int 

+ 

int  *  int  — ►  int 

— 

int  *  int  — >  int 

* 

int  *  int  — >  int 

div 

int  *  int  — >  int 

min 

int  *  int  —>  int 

max 

int  *  int  —>  int 

mod 

int  *  int  — ►  int 

< 

int  *  int  — >  o 

< 

int  *  int  — >  o 

= 

int  *  int  — >  o 

> 

int  *  int  — >  o 

> 

int  *  int  — >  o 

int  *  int  — >  o 

Figure  3.3:  The  signature  of  the  integer  domain 


Mh  :  int.Ml 
Mh  :  int.Ml 
Mh  :  int.Ml 
Mh  :  int.Ml 
Mh  :  int.Ml 


nat.Msize  :  nat.( 0  <  h  +  1  < 
nat.Msize  :  nat.( 0  <  h  +  1  < 
nat.Msize  :  nat.( 0  <  h  +  1  < 
nat.Msize  :  nat.( 0  <  h  +  1  < 
nat.Msize  :  nat.{ 0  <  h  +  1  < 


size  A  0  <  l  <  size  A  h  >  l) 
size  A  0  <  l  <  size  A  h  >  l) 

size  A  0  <  l  <  size  A  h  >  l) 

size  A  0  <  l  <  size  A  h>  l) 

size  A  0  <  l  <  size  A  h  >  l) 


D  (l  +  (h  —  0/2)  <  size 
D  0  <  l  +  (h-l)/2-  1  +  1 
D  l  +  (h  —  Z)/2  —  1  +  1  <  size 
DO  <l  +  (h-  0/2  +  1 
D  l  +  (h  —  Z)/2  +  1  <  size 


Figure  3.4:  Sample  constraints 
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into 

a\X\  “t-  "1"  OjYiXn  —  &  ? 

where  a'  is  the  largest  integer  such  that  a!  <  a  and  the  greatest  common  divisor  of  a\, ...  ,an 
divides  a'.  This  is  used  in  type-checking  an  optimized  byte  copy  function  in  Section  A. 5. 

The  above  elimination  method  can  be  extended  to  be  both  sound  and  complete  while  remaining 
practical  (see,  for  example,  (Pugh  and  Wonnacott  1992;  Pugh  and  Wonnacott  1994)).  We  hope  to 
use  such  more  sophisticated  methods  which  still  appear  to  be  practical,  although  we  have  not  yet 
found  the  need  to  do  so  in  the  context  of  our  current  experiments. 


3.3.2  An  Example 

We  show  how  the  following  constraint  is  solved  with  the  above  approach. 

\/h  :  int.Vl  :  natS/size  :  nat.( 0  <  h  +  1  <  size  A  0  <  l  <  size  A  h  >  I)  D  l  +  (h  —  I)/2  +  1  <  size 

The  first  step  is  to  negate  the  constraint  and  transform  it  into  the  following  form. 

I  >  0  size  >0  0  <  h  +  1  h  +  1  <  size  l  <  size  h>  l  1  +  (h  —  l)/ 2  +  1  >  size 

Then  we  replace  {h  —  l ) /2  with  D  and  add  h  —  l  —  1  <  2D  <  h  —  l  into  the  set  of  linear  inequalities. 
We  now  test  for  the  unsatisfiability  of  the  following  set  of  linear  inequalities. 

I  >  0  size  >0  0  <  h  +  1  h  +  1  <  size  l  <  size  h  >  l 
h  —  l  —  1  <  2D  2D  <  h  —  l  l  +  D  >  size 

We  now  eliminate  variable  size,  yielding  the  following  set  of  inequalities. 

Z>0  l  +  D>  0  0<h+l  h+l<l  +  D  l  <l  +  D  h  >  l 

h-l-l<2D  2D  <  h  -  l 

We  then  eliminate  variable  D  and  generate  the  following  set  of  inequalities. 

£>0  —2 1  <  h  —  l  0  <  h  +  1  2h  —  21  +  2  <  h  —  l  0  <  h  —  l  h  >  l  h  —  l  —  1  <  h  —  l 

If  we  eliminate  variable  h  at  this  stage,  the  inequality  l  <  l  —  1  is  then  produced,  which  leads  to  a 
contradiction.  Therefore,  the  original  constraint  has  been  verified. 

The  Fourier  variable  elimination  method  can  be  expensive  in  practice.  We  refer  the  reader  to 
(Pugh  and  Wonnacott  1994)  for  a  detailed  analysis  on  this  issue.  However,  we  feel  that  this  method 
is  intuitive  and  therefore  can  facilitate  informative  type  error  message  report  if  some  constraints 
can  not  be  verified. 

We  have  observed  that  an  overwhelming  majority  of  the  constraints  gathered  in  practice  are 
trivial  ones  and  can  be  solved  with  a  sound  and  highly  efficient  (but  incomplete)  constraint  solver 
such  as  one  based  on  the  simplex  method  for  reals.  Therefore,  a  promising  strategy  is  to  use  such 
an  efficient  constraint  solver  to  filter  out  trivial  constraints  and  then  use  a  sound  and  complete 
(but  relatively  slow)  constraint  solver  to  handle  the  rest  of  the  constraints. 
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3.4  Summary 

In  this  chapter,  we  have  presented  a  general  constraint  language  in  which  constraint  domains  can 
be  constructed.  It  will  soon  be  clear  that  the  dependent  type  system  that  we  develop  parameterizes 
over  a  given  constraint  domain.  The  ability  to  find  a  practical  constraint  solver  for  a  constraint 
domain  is  crucial  to  making  type-checking  feasible  in  the  dependent  type  system  parameterizing 
over  it. 

At  this  moment,  there  is  no  mechanism  to  allow  the  user  to  define  a  constraint  solver  for 
a  declared  constraint  domain.  Some  study  on  formulating  such  a  mechanism  can  be  found  in 
(Friihwirth  1992).  Also  there  is  a  great  deal  of  study  on  how  to  define  constraint  solvers  and  make 
them  more  efficient  in  the  constraint  logic  programming  community,  and  (Jaffar  and  Maher  1994) 
is  an  excellent  source  to  draw  inspiration  from. 


CHAPTER  3.  CONSTRAINT  DOMAINS 


Chapter  4 

Universal  Dependent  Types 


In  this  chapter  we  enrich  the  type  system  of  MLo  with  universal  dependent  types,  yielding  a 
language  ML^(C),  where  C  is  some  fixed  constraint  domain.  We  then  present  the  typing  rules 
and  operational  semantics  for  ML^(C)  and  prove  some  crucial  properties,  which  include  the  type 
preservation  theorem  and  the  relation  between  the  operational  semantics  of  MLq  (C)  and  that  of 
MLo-  Also  we  prove  that  ML^(C)  is  a  conservative  extension  of  MLo- 

In  order  to  make  ML^C)  a  practical  programming  language,  we  design  an  external  language 
DMLo(C)  for  ML^((7).  We  address  the  issue  of  unobtrusiveness  of  programming  in  DMLo(C') 
through  an  elaboration  mapping  which  maps  a  program  in  DMLo(C')  into  one  in  ML^C1).  We  then 
prove  the  correctness  of  the  elaboration.  This  elaboration  process,  which  reduces  type-checking  a 
program  into  constraint  satisfaction,  accounts  for  a  major  contribution  of  the  thesis.  Finally,  we 
use  a  concrete  example  to  illustrate  the  elaboration  in  full  details  since  it  is  a  considerably  involved 
process. 

This  extension  primarily  serves  as  the  core  of  the  language  that  we  will  eventually  develop,  and 
it  also  demonstrates  cleanly  the  language  design  approach  we  take  for  making  dependent  types 
available  in  practical  programming. 


4.1  Universal  Dependent  Types 

We  now  present  ML^C),  which  is  an  extension  of  MLo  with  universal  dependent  types.  Given 
a  constraint  domain  C,  the  syntax  of  ML^C)  is  given  in  Figure  4.1.  We  use  5  for  base  type 
families,  where  we  use  5(())  for  an  unindexed  type.  Type  and  context  formation  rules  are  listed  in 
Figure  4.2.  A  judgement  of  form  (f>  h  r  :  *  means  that  r  is  a  well-formed  type  under  index  context 
4>,  and  a  judgement  of  form  (/>  h  T[ctx]  means  that  T  is  a  well-formed  context  under  cj).  Notice  that 
a  major  type  is  a  type  which  does  not  begin  with  a  quantifier. 

The  domains  of  T  and  (j)  are  defined  as  usual.  Note  that  every  substitution  6  can  be  thought 
of  as  the  union  of  two  substitutions  9 ^  and  0p,  where  dom(0^)  contains  only  index  variables  and 
dom(0p)  contains  only  (ordinary)  variables. 

We  do  not  specify  here  how  new  type  families  or  constructor  types  are  actually  declared, 
but  assume  only  that  they  can  be  processed  into  the  form  given  above.  Our  implementation 
provides  indexed  refinement  of  datatype  declarations  as  shown  in  Section  1.1.  The  syntax  for  such 
declarations  will  be  mentioned  in  Chapter  8. 
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families 

(5  : 

:=  (family  of  refined  datatypes) 

signature 

5  : 

:=  -5  \  S,  6  :  7  — >■  * 

|  S,  c  :  Ilai  :  7i . . .  Han  :  7 n.5(i) 

|  S,  c  :  Ilai  :  71 . . .  IIan  :  7 n.r  — >■  e>(i) 

major  types 

P  : 

:=  <5(i)  |  1  |  (n  *  r2)  1  (ti  ->•  r2) 

types 

r  : 

:=  fi  |  (na  :  7-r) 

patterns 

P 

:=  x  |  c[ai]  . . .  [an]  |  c[oi]  . . .  [a„](p)  |  ()  |  (pi,p2) 

matches 

ms 

:=  (p  =>•  e)  |  (p  =$■  e  |  ms) 

expressions 

e 

:=  x  |  ()  (ei,  e2)  |  c[u]  . . .  [in]  \  c[i  1]  . . .  [in](e) 

(case  e  of  ms)  (lam  x  :  r.e)  ei(e2) 
let  x  =  ei  in  e2  end  (fix  /  :  t.u) 

|  (Aa  :  7-e)  |  e[i] 

value  forms 

u 

:=  c[*i] . . .  [i„]  |  c[*i]  . . .  [in] (it)  |  ()  |  {ui,u2) 

(lam  x  :  r.e)  (Aa  :  7 .it) 

values 

V 

:=  x  |  c[ii] . . .  [in]  |  c[ii]  . . .  [ in](v )  |  ()  |  (xi,x2) 

(lam  x  :  r.e)  (Aa  :  7.x) 

contexts 

T  : 

:=  •  |  T,  x  :  t 

index  contexts 

0 

:=  •  |  <£,a  :  7  | 

substitutions 

6  : 

:=  []  #[x  i->  e]  0[a  i-»  i] 

Figure  4.1:  The  syntax  for  ML^(C) 


S(5)  =  7  — >  *  (j)\-  i  :  'y 


4>  b  6(i)  :  * 
b  </>[ictx] 


(type-datatype) 


(j)  b  T\  :  *  (/>  b  T2  :  * 


(type-unit) 


4>  b  n  =>•  T2  :  * 
0  b  Ti  :  *  0  b  T2  :  * 


(type-match) 


<f>  b  1  :  * 

<p  b  Ti  :  *  (j)  b  72  :  * 


4>  b  n  — >  T2  :  * 

(ctx-empty) 


(type-fun) 


(f>  b  (ri,r2)  :  * 

4>,  a  :  7  b  r 


<fi  b  •  [ctx] 


(f>  b  Ila  :  7-T 

(j)  b  T[ctx]  ^br:* 
()br,.T:  r[ctx] 


(type-prod) 
(type-pi) 
(ctx-var) 


Figure  4.2:  The  type  formation  rules  for  MLq 
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Figure  4.3:  Typing  rules  for  patterns 


4.1.1  Static  Semantics 


We  start  with  the  typing  rules  for  patterns,  which  are  listed  in  Figure  4.3.  The  judgment  p  j 
r  >  (0;  r)  expresses  that  the  index  and  ordinary  variables  in  pattern  p  have  the  types  declared  in 
<f>  and  r,  respectively,  if  we  know  that  p  must  have  type  r. 

We  write  <f>  |=  r  =  t'  for  the  congruent  extension  of  0  j  =  i  =  j  from  index  objects  to  types, 
which  is  determined  by  the  following  rules. 


4>\  =i  =  j 
<t>  \=  <*(*)  =  8(j) 

4>  1=  T[  =  n  (j)  |=  r2  =  Tg 
<t>  1=  n  ->  T2  =  t[  ->  t'2 


(t>  |=  Tl  =  t{  |=  r2  =  Ta 
4>  1=  T\  *  T2  =  t[  *  T.j 
0,  a  :  7  |=  r  =  t' 

4>  |=  Ila  :  7 .r  =  Ila  :  7 .t' 


Proposition  4.1.1  If  both  (j)\~  0  :  <f>'  and  4>,(j)'  |=  ri  =  72  are  derivable,  then  f>  |=  ri[0]  =  T2[0] 
also  derivable. 


Proof  This  simply  follows  from  a  structural  induction  on  the  derivation  of  (f>  |=  T\  =  T2,  with  the 
application  of  Proposition  3.1.2  (3).  ■ 

We  now  present  the  typing  rules  for  MLq  (C)  in  Figure  4.4.  We  require  that  there  be  no  free 
occurrences  of  a  in  r(x)  for  every  x  £  dom(r)  when  the  rule  (ty-ilam)  is  applied.  Also  note  that 
one  premise  h  T2  :  *  of  the  rule  (ty-match)  enforces  that  all  index  variables  in  r  are  declared  in 
(f.  The  rule  (ty-cons-wo)  applies  only  if  c  is  a  constructor  without  an  argument.  If  c  is  with  one 
argument,  the  rule  (ty-cons-w)  applies. 

Proposition  4.1.2  (Inversion)  If  b  e  :  r  is  derivable,  then  the  last  inference  rule  of  any 
derivation  of  <f  \  T  h  e  :  r  is  either  (ty-eq)  or  uniquely  determined  by  the  structure  of  e. 


Proof  By  an  inspection  of  all  the  typing  rules  in  Figure  4.4.  ■ 

This  proposition  will  be  frequently  used  to  do  structural  induction  on  typing  derivations  since  it 
allows  us  to  determinate  the  last  applied  rule  in  such  derivations. 
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t>;  r  b  e  :  T\  0  | =  ti  =  r2 


0;  T  b  e  :  r2 
0  b  r[ctx]  T(x)  =  r 


(ty-eq) 


(ty-var) 


0;  T  b  x  :  r 

5(c)  =  Hai  :  71 . . .  IIan  :  7n.<5(z)  0  b  ii  :  71  •  •  •  0  b  in  :  7„  0  b  T[ctx] 


0;  T  b  c[ii]  . . .  [in]  :  <S(i[ai, . . . ,  an  (-»•  ii, . .  .,*„]) 

5(c)  =  ITai  :  71 . . .  a„  :  7n.r  -»•  <5(i) 

0  b  ii  .  71  •  0  b  in  .  7n  0,  r  b  e  .  t[q>i,  .  .  .  ,  Qn  1  *  ilj  •  •  >  in] 

0;  r  b  c[ii] . . .  [in](e)  :  5(i[ai, . . . ,  an  ^  i±, . . . ,  in]) 

0  b  r[ctx] 


(ty-cons-wo) 


(ty-cons-w) 


0;T  b  ()  :  1 

0;  r  b  ei  :  n  0;  T  b  e2  :  r2 
0;  r  b  (ei,e2)  :  ri  *  r2 
p|Ti>(0/;r/)  0,0';r,r'be:r2  0  b  r2  :  * 


0;  T  b  p  =>•  e  :  ti  r2 
0;  T  b  (p  =$■  e)  :  ri  r2  0;  T  b  ms  :  T\  =$ 
0;  T  b  (p  =$■  e  |  m-s)  :  ri  r2 
0;  T  b  e  :  ri  0;  T  b  ms  :  77  r2 
0;  T  b  (case  e  of  ms)  :  t2 
0,  a  :  7;  T  b  e  :  r 
0;  r  b  (Aa  :  y.e)  :  (Ila  :  7.7") 

0;  T  b  e  :  Ila  :  7 .r  0  b  i  :  7 
0;  T  b  e[i]  :  r[a  1— >  i] 

0;  r,  x  :  T\  b  e  :  r2 
0;  T  b  (lam  x  :  r\.e)  :  ri  — >  r2 
0;  T  b  ei  :  ri  — >  r2  0;  T  b  e2  :  n 
0;  T  b  d(e2)  :  r2 

0;  r  b  ei  :  Ti  0;  T,  x  :  T\  b  e2  :  t2 
0;  r  b  let  x  =  ei  in  e2  end  :  t2 
0;r,/:rbii:r 


(ty-unit) 

(ty-prod) 

(ty-match) 


(ty-matches) 
(ty-case) 
(ty-ilam) 

(ty-iapp) 

(ty-lam) 

(ty-app) 

(ty-let) 


0;  T  b  (fix  /  :  t.u)  :  r 


(ty-fix) 


Figure  4.4:  Typing  Rules  for  ML?(C) 
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match(.T.  v ) 


- - -  (match-var) 

[x  i— >  v\ 

- -  (match-unit) 


match(  (),())  =! 
match(pi,vi)  =>■  9\  match(p2,^2)  =>-  #2 
match((pi,p2),  v)  =*>  6*1  U  92 


match(c[ai]  . . .  [an\,  c[i\\  . . .  [*„])  =*>  [a\  ^  i\, . . .  ,an  ^  in]U 

match(p,  v)  =$■  9 

match(c[ai]  . . .  [an\(p) ,  c[h] . . .  [in](u))  =*>  [ai  ft, . . . ,  an  (->•  in]  U  9 


(match-prod) 

(match-cons-wo) 


(match-cons-w) 


Figure  4.5:  The  pattern  matching  rules  for  ML^C) 


Next  we  turn  to  the  operational  semantics.  Matching  a  pattern  p  against  a  value  v  yields  a 
substitution  9,  whose  domain  includes  both  index  and  ordinary  variables,  written  as  the  judgment 
match(p,  v)  =>  9. 

Given  F,(j>,F',ft  and  9 ,  a  judgement  of  form  ftF  b  9  :  (ft:  T7)  can  be  derived  through  the 
application  of  the  following  rules. 


ftFh  (}:(.;■) 

&;Tb  9:(ft;F')  ftFV-e-.r 


ft  T  b  9[x  h- »  e]  :  ( ft ;  P,  x  :  r) 


(subst-empty) 

(subst-var) 


ftFL9:(ft;F')  ^hi:7 


ft,  T  b  9[a  1— ►  i]  :  (ft ,  a  :  7;  P) 
ft  T  b  9  :  (</>';  P)  ftfth  P:o  <j>  |=  P[0] 
ftF  \~  9  :  (ft  ,P;F') 


—  (subst-ivar) 

(subst-iprop) 


The  meaning  of  a  judgement  of  form  ftF  \~  9  :  (ft;  P)  is  given  in  the  proposition  below. 
Proposition  4.1.3  If  ft  F  b  9  :  (ft;F')  is  derivable,  then 

dom(T/)  =  dom(0r)  and  domf^)  =  dom(0^), 
and  4>  |=  P[9\  is  derivable  for  every  index  proposition  P  declared  in  ft . 


Proof  This  directly  follows  from  a  structural  induction  on  the  derivation  ftF  \~  9  :  (ft;  P) .  ■ 

Lemma  4.1.4  (Substitution)  If  <f,ft;F,F’  b  e  :  r  and  ftF  b  9  :  (ft;Fr)  are  derivable,  then 
ft,  F  b  e[9]  :  t[9\  is  derivable. 


Proof  This  follows  from  a  structural  induction  on  the  derivation  V  of  (f>,  ft;  Td' be:r,  parallel 
to  the  proof  of  Lemma  2.2.4.  We  present  some  cases. 
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<t>,  <P'\  r,  r'  h  e  :  n  (f>,  cp’  |=  n  =  r2 

<p,  cp';  T,  T'  I -  e  :  r2  By  induction  hypothesis,  h  e\0\  :  ri[0]  is  deriv¬ 

able.  Clearly,  (p  b  9(p  :  <p'  is  also  derivable,  and  this  implies  that  cp  |=  ti[0^]  =  r2[#^]  is 
derivable.  We  then  have  the  following. 


<P\  T  I-  e[9]  :  ri[6>0]  cp  \=  n[9^\  =  -r2 [6>^] 
b  e[0]  :  r2[^] 


(ty-eq) 


By  the  definition  of  9 Tj[#0]  =  t*[$]  for  1  =  1,2.  This  concludes  the  case. 


^If;r,r'l-e1:r1  <p,(p'\T,T'  b  e2  :  r2 

<(>,  i^/^T'  b  (ei,e2)  :  n  *  r2  By  induction  hypothesis,  (p;  V  b  ei[6]  :  n[9 ]  are 

derivable  for  i  =  1,2.  This  leads  to  the  following  derivation. 

(p;T  \- ei[9]  :  n[9]  (p]  T  b  e2  [6>]  :  r2  [9] 

(p-rh(e1[9},e2[9}):r1[9}*r2[9}  K  Y'Pr°  ’ 


Since  (ei,e2}[0]  =  (e\[9], e2 [<9] )  and  (ti  *  r2)[0]  =  t\[9]  *  r2[$],  we  are  done. 

All  other  cases  can  be  handled  similarly.  ■ 

Lemma  4.1.5  Assume  that  there  is  no  a  G  dom(^)  which  occurs  in  pattern  p.  If  (p;T  b  v  :  r, 
p  i  r  D>  ((/>';  T')  and  match(p,  v)  9  are  derivable,  then  0;T  b  9  :  ((/>';  T')  is  derivable. 


Proof  This  follows  from  a  structural  induction  on  the  derivation  V  of  p  j  r  >  (<p'-,T'),  parallel 
to  the  proof  of  Lemma  2.2.5.  Since  there  is  no  a  E  dom(</>)  which  occurs  in  pattern  p,  dom(^)  n 
dom(6y  =  0.  We  present  one  interesting  case  where  v  =  c[ai]  . . .  [an](ui). 

match(pi,ui)  =i>  9 1 

D  = - 

match(c[ai]  . . .  [an](pi),  c[ii] . . .  [in](fi))  =>■  [ai  i— ►  . ,  an  i— ►  in ]  U  9 \  Then  the  deriva¬ 

tion  of  p  |  r  D>  {(p']  T')  must  be  of  the  following  form, 

5(c)  =  Ilai  :  7i . . .  IIan  :  7„.(ri  ->  5(i))  pi  in>  (cp[;  V) 

— — - - — — — - — - - — —  (pat-cons-w) 

c[aij  . . .  KJ(pi)  |  d{j)  >  (ai  :  71, . . . ,  an  :  7n,  i  =  j,  <pR  T  ) 

where  r  =  5(j)  and  cp'  =  a\  :  71, . . . ,  an  :  7n,  i  =  j,  (p\ .  By  induction  hypothesis,  </>;  V  b  9\  : 
(cp\ ;  T7)  is  derivable.  Let  us  first  suppose  that  the  derivation  of  cp;  T  b  v  :  t\  is  of  the  following 
form, 


5(c)  =  Ilai  :  71 . . .  an  :  7„.ri  -*■  <5(i) 

(p\~  i\  .  71  •  (p  in  .  7n  (pi  T  b  Ui  .7"!  [fli ,  •  •  • ,  an  l  >  ^  1 ,  .  .  .  ,  *n] 
0;T  b  c[ii]  . . .  \in\{vi)  :  <5(i[ai, . . . ,  an  h, . . .  ,in}) 


(ty-cons-w) 


where  z[ai, . . . ,  a„  1— ►  ii, . . . ,  in]  is  j.  Clearly,  we  have  <p  \=  i[9]  =  j[9 ]  since 

i[9]  =  i[ai,  ...,an^ii,...,in]=j  =  j[9]. 
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It  then  immediately  follows  that  0;  T  b  9  :  (< p'\T ')  is  derivable.  Note  that  can 

also  be  derived  as  follows, 


0;  r  b  v  :  n  (j)\=  t\=t 
(f;  r  b  v  :  t 


(ty-eq) 


where  t\  =  6(j i)  for  some  j\  and  (f>;  T  h  v  :  t\  is  derived  with  an  application  of  (ty-cons-w). 
Then  j\  is  i[a\, . . . ,  an  i— ■ ►  . . . ,  in].  We  can  infer  (f>  |=  j\  =  j  from  cf>  \=  t±  =  t.  This  implies 

</>  |=  i[9]  =  j i  =  j  =  j[9],  leading  to  a  derivation  of  (/>-,  T  b  9  :  (^/;  T'). 

All  other  cases  can  be  treated  similarly.  ■ 

Lemma  4.1.5  is  crucial  to  proving  the  type  preservation  theorem  for  MLq  (C),  which  is  formulated 
as  Theorem  4.1.6. 


4.1.2  Dynamic  Semantics 

The  natural  semantics  of  MLjj^C)  is  given  through  the  rules  in  Figure  4.6.  Note  that  e  c— v 
means  that  e  reduces  to  a  value  v  in  this  semantics. 

Notice  that  type  indices  are  never  evaluated.  This  highlights  the  language  design  decision  we 
have  made:  there  exist  no  direct  interactions  between  indices  and  code  execution.  The  reasoning 
on  type  indices  requires  constraint  satisfaction  done  statically  during  type-checking. 

Theorem  4.1.6  (Type  preservation  in  ML^((7) )  Given  e,  v  in  ML^C*)  such  that  e  v  is  deriv¬ 
able.  If  </>;  T  b  e  :  r  is  derivable,  then  4>]T  b  v  :  r  is  derivable. 


Proof  The  theorem  follows  from  a  structural  induction  on  the  derivation  V  of  e  v  and  the 
derivation  of  (/>;  T  b  e  :  r,  lexicographically  ordered.  If  the  last  rule  in  the  derivation  of  0;  T  h  e  :  r 
is 


f>;  T  b  e  :  t'  (f>\~  t'  =  t 
<f>]  T  h  e  :  t 


(ty-eq) 

5 


then  by  induction  hypothesis  </>;  T  b  v  :  r'  is  derivable,  and  therefore  we  have  the  following. 


(f;  T  h  v  :  t'  <f>\=  t'  =  t 
(j)-,  T  b  v  :  t 


(ty-eq) 


This  allows  us  to  assume  that  the  last  rule  in  the  derivation  of  4>;  T  h  e  :  r  is  not  (ty-eq)  in  the 
rest  of  the  proof.  We  present  several  cases. 


eo  5 — >d  vo  match(uo,Pfc)  9  for  some  1  <  k  <  n  ek[9 ]  d  v 

(case  eo  of  p\  e\  \  ■  ■  ■  \  pn  en)  ^ d  v  Then  by  Proposition  4.1.2, 

the  last  rule  in  the  derivation  of  4>;  T  h  e  :  r  is  of  the  following  form. 

(f-T  \~  e0  :  to  (j)\  T  h  (pi  =>  ei  |  •  •  •  |  pn  en)  :  r0  r 

- — - : - : - rr -  (ty-case) 

<p;  r  r  (case  e0  of  (pi  ^  ei  •  •  •  \pn  en))  :  r 
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x  d  x 


(ev-var) 


c[h\  .  ■  .  [in]  c-> d  c[il]  .  .  .  [in] 

e<->dv 


c[ii]  ■  ■  ■  [ in](e )  c-»d  c[h] . . .  [ in](v ) 

(ev-unit) 


(ev-cons-wo) 
(ev-cons-w) 


0  ^  0 

ei  ^ d  v\  e2  c-> d  V2 


(ev-prod) 


(ei,e2)  ^ d  ( vi,v2 } 
d  vo  match(uo,p/c)  =>•  0  for  some  1  <  k  <  n  ek[0]  >d  v 
(case  e0  of  (pi  =*>  ei  |  •  •  •  |  pn  =>  en))  <-► d  v 
e^dv 


(ev-case) 


(A a  :  7-e)  ^ d  (A a  :  'y.v) 


(ev-ilam) 


e  <-► d  (A a  :  'y.v ) 


e[*J  ^ d  v[a 


-  (ev-iapp) 


- - r - - - -  (ev-lam) 

(lam  x  :  r.ej  c— > d  (lam  x  :  r.e ) 

ei  d  (lam  x  :  r.e)  e2  ^ d  v2  e[x  ^  v2]  ^ d  v 


ei(e2)  d  v 

ei  c— v\  e2[x  ^  vi]^dV2 
(let  x  =  e\  in  e2  end)  ^d  v2 


(ev-app) 


(fix  /  :  r.u)  ■-* d  u[f  1  *  (fix  /  :  r.u)] 


(ev-let) 
(ev-fix) 


Figure  4.6:  Natural  Semantics  for  MLq  (C) 
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Clearly,  we  also  have  the  following. 


Pk  I  To  D>  (</>';  T')  </>,<//;  r,  r  h  efc  :  t  ~r:* 

</>;  T  h  (pk  =>  ek)  :  (r0  =>-  r) 


(ty-match) 


By  induction  hypothesis,  h  vq  :  To  is  derivable.  Therefore,  T  P  0  :  ((/>';  T')  is  derivable 
by  Lemma  4.1.5.  This  implies  that  </>;  T  h  ek[0\  :  r  is  derivable  by  Lemma  4.1.4  since  r  =  t[6\. 
By  induction  hypothesis,  </>;  T  h  v  :  r  is  derivable. 


ei  d  vi 

V  = - 

(A a  :  7-ei)  (Ao  : 

where  Lla  :  7.77  =  r. 
the  following. 


7.77)  Then  by  Proposition  4.1.2,  a  :  7;  T  h  e\  :  ri  is  derivable, 
By  induction  hypothesis,  (f),  a  :  7;  T  h  17  :  77  is  derivable,  and  this  yields 


<t>,  a  :  7;  T  P  v\  :  n 
^>;T  h  (Ao  :  7.77)  :  (Lla  :  7.T1) 


(ty-ilam) 


ei  (Aa  :  7.17) 

ei  [i]  77  [a  1— >  i]  Then  by  Proposition  4.1.2,  we  have  a  derivation  of  the  following  form, 


</>;  T  P  ei  :  (Lla  :  7.T1)  P  i  :  7 
0;  r  h  ei[i]  :  r 


(ty-iapp) 


where  r  =  ri[aH>j],  By  induction  hypothesis,  0;  T  h  (Aa  :  7.77)  :  (Lla  :  7.77)  is  derivable,  and 
this  yields  that  (j>,  a  :  7;  T  P  77  :  77  is  derivable.  By  Lemma  4.1.4,  0;  F  h  77  [a  1— ►  i\  :  77  [a  i] 
is  derivable. 


All  other  cases  can  be  handled  similarly.  ■ 

We  have  no  intention  to  construct  an  interpreter  or  a  compiler  following  the  natural  semantics 
of  MLq  (C).  Instead,  we  intend  to  use  existing  compilers  of  ML  to  compile  programs  written  in 
ML^C1 2).  The  following  index  erasure  function  ||  •  ||  is  mainly  introduced  for  this  purpose.  Note  that 
this  is  different  from  the  type  erasure  function  |  •  |.  Roughly  speaking,  the  index  erasure  function 
erases  everything  related  to  type  index  objects,  mapping  MLq  (C)  programs  into  MLo  ones. 

Definition  4.1.7  The  index  erasure  function  ||  •  ||  is  defined  in  Figure  f.7.  which  maps  an  expres¬ 
sion  in  MLq  (C)  into  one  in  MLo- 

In  order  to  justify  that  the  index  erasure  function  does  what  it  is  supposed  to  do,  we  have  to  show 
that  the  index  erasure  of  an  ML^(C)  program  behaves  properly  in  the  following  sense. 

1.  Given  an  ML^(C)  program  e  which  evaluates  to  v  according  to  the  natural  semantics  of 
MLq  (C),  we  must  verify  that  |je||  evaluates  to  ||o||  according  to  the  natural  semantics  of 
ML0. 

2.  Given  an  MLq  (C)  program  e  whose  erasure  ||e||  evaluates  to  vo  according  to  the  natural  se¬ 
mantics  of  MLo,  we  must  verify  that  e  evaluates  to  some  v  according  to  the  natural  semantics 
of  ML^((7)  such  that  ||u||  =  vq- 
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|i|| 

1 

m\\ 

= 

6 

Ila  :  7 .r  | 

= 

r 

Tl  *  T2  || 

= 

n||  *  INI 

In  ->  r2|| 

= 

llnll -  INI 

= 

X 

|c[ii]...[?:n]|| 

= 

c 

|c[*i]...[i„](e)|| 

= 

c(||e||) 

1011 

= 

0 

1  <ei,  e2> || 

= 

(INI,  INI) 

\p  =7>  e  ms  | 

= 

\\p\\  e  ms 

(case  e  of  ms) 

= 

(case  e  of  ms  ) 

(lam  x  :  r.e) 

= 

(lam  x  :  r  .  e  ) 

|ei(e2)  || 

= 

II  ei  ||  ( ||  e2 1| ) 

(Aa  :  7-e)  | 

= 

||  e  | 

|e[i]|| 

= 

e 

let  x  =  e\  in  e2  end 

= 

let  x  =  ||ei ||  in  e2  end 

fix  /  :  t.u\\ 

= 

fix  /  :  |r  |. \\u  | 

T,  x  :  r  | 

= 

llrIN  :  llTll 

•5 

= 

•5 

<S,  5  :  7  — ►  *|| 

= 

IISIIN* 

<S,  c  :  r 

= 

5 II,  c  :  \\t\\ 

ID  II 

= 

0 

\0[a  i— >  i] 

= 

Ml 

\9[x  i— >  e] 

= 

Il^lll*  —  INI] 

Figure  4.7:  The  definition  of  erasure  function 


(1)  and  (2)  will  be  proven  as  Theorem  4.1.10  and  Theorem  4.1.12,  respectively. 

Proposition  4.1.8  We  have  the  following. 

1.  ||t[0]||  =  ||t||  and  \\e[0}\\  =  \\e\m\\. 

2.  ||u||  is  a  value  form  in  MLo  if  u  is  a  value  form  in  MLq(C). 

3.  ||u||  is  a  value  in  MLo  if  v  is  a  value  in  ML^(C). 

4 ■  If  p  |  r  >  (</>;T)  is  derivable,  then  ||p||  j  ||r||  D>  ||r||  is  derivable. 

5.  //match(p,  v)  =>  9  is  derivable  in  ML^((7);  then  match(||p||,  [)u||)  =>  ||0||  is  derivable  in 
ML0. 
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6.  Given  v,p  in  MLq(C')  such  that  (f>;T  b  v  :  r  and  p  |  r  =$■  (</>;T)  are  derivable.  If 
match(||p||,  ||u||)  =>  0o  is  derivable,  then  match(p,  v)  ==>■  6  is  derivable  for  some  0  and 

11*11=  ft). 

7.  If  4>  \=  T\  =  T2  is  derivable,  then  ||ti||  =  ||t"2 || - 

Proof  We  omit  the  proofs  of  (1),  (2)  and  (3),  which  are  straightforward.  (4)  is  proven  by  a 
structural  induction  on  the  derivation  T>  of  p  j  r  D>  (</>;  T),  and  we  present  one  case  below.  Let  V 
be  a  derivation  of  the  following  form. 


‘5(c)  =  Ilai  :  71 . . .  nan  :  7„.(r  — >  5(i))  p[r  >  (<f>;  T) 

— — - —  - 7 - .  .  r~rw  (pat-cons-w) 

cai  . . .  a„  (p)  f  <)(j)  >  (ai  :  71,...  ,an  :  7n,z  =  j, <p; P) 


By  induction  hypothesis,  we  have  the  following  derivation. 


I|5||(c) 


Ibll  I  IMI  >  ||r 
c(lbll)  I £>  l|r|| 


(pat-cons-w) 


Notice  that  ||c[ai]  . . .  [an](p)||  =  c(||p||),  \\5(j)\\  =  5  and 

||(ai  :  71 ,..., on  :  TnP  =  j,(/>]T)\\  =  l|T 


Hence  we  are  done. 

(5)  follows  from  a  straightforward  structural  induction  on  the  derivation  V  of  match(p,  v) 
0.  We  present  one  case  below. 


match(p,  v)  = =7  9 

match(c[ai] . . .  [an\(p),  c[*i]  . . .  [in](^))  ==>•  [01  i— >  i\, . . . ,  an  i— >  in]  U  9  By  induction  hypoth¬ 
esis,  match(||p||,  ||v||)  =$■  ||0||.  This  leads  to  the  following. 


match(jjpjj,  \\y\\)  =7-  ||fl|| 
match(c(||p||),c(||u||))  =►  ||0| 


(match-cons-w) 


Since  ||c[oi] . . .  [an](p)||  =  c(||p||),  ||c[n]  •  •  •  [*n](c)||  =  c(||w||)  and 

|| [01  h->.  ii, . . .  ,an  in\  u  9 1|  =  ||0||, 


we  are  done. 

All  other  cases  can  be  treated  similarly. 

The  proof  of  (6)  proceeds  by  a  structural  induction  on  the  derivation  of  match(||p||,  ||u||)  ==$■  6q, 
parallel  to  that  of  (5).  (7)  is  then  proven  by  a  structural  induction  on  the  derivation  of  <p  \=  n  =  72. 


Theorem  4.1.9  If  <f;T  h  e  :  t  is  derivable  in  MLq  (C),  then  ||r||  h  |je|j  :  ||r||  is  derivable  in  MLq. 
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Proof  This  simply  follows  from  a  structural  induction  on  the  derivation  of  T  b  e  :  r.  ■ 

We  say  that  an  expression  e  in  ML^((7)  (MLo)  is  typable  if  </>;  T  h  e  :  r  (T  h  e  :  r)  is  derivable 
for  some  </>,  T,  r  in  ML^((7)  (for  some  T,r  in  MLo).  Also  we  say  that  an  untyped  expression  e  in 
A^  is  typable  in  ML^(C)  (MLo)  if  e  is  the  type  erasure  of  some  typable  expression  in  ML^(C) 
(MLo).  In  this  sense,  it  is  clear  from  Theorem  4.1.9  that  there  are  no  more  expressions  in  Ajv'J' 
which  are  typable  in  ML^(C)  than  are  typable  in  MLo-  On  the  other  hand,  there  has  been  a  great 
deal  of  research  on  designing  type  systems  so  that  strictly  more  expressions  in  A^  are  typable 
in  these  type  systems  than  are  typable  in  MLo-  For  instance,  the  type  system  extending  MLo 
with  let-polymorphism  allows  more  expressions  in  A^m  to  be  typable.  In  this  respect,  our  work 
is  significantly  different.  Roughly  speaking,  our  objective  is  to  assign  expressions  more  accurate 
types  rather  than  make  more  expressions  typable. 

Theorem  4.1.10  If  e  ^>d  v  derivable  in  ML^(C),  then  ||e||  ^o  IMI  derivable. 


Proof  This  simply  follows  from  a  structural  induction  on  the  derivation  V  of  e  ^>d  v •  We  present 
a  few  cases  as  follows. 

eo  c— i >d  vo  match(uo,Pfc)  =>  0  for  some  1  <  k  <  n  ek[0]  c— v 

(case  eo  of  p\  =4>  ei  |  •  •  •  |  pn  =$■  en)  <—>d  v  Then  by  induction  hypoth¬ 

esis,  || eo ||  c — >o  Kll  is  derivable.  By  Proposition  4.1.8  (5),  match(||pfc||,  ||uo||)  =>■  ||0||  is 
derivable.  By  induction  hypothesis,  j|efc||[||0||]  ^->o  ||v||  is  derivable  since  ||efc[0]||  =  ||e/,:||  [||0||] 
by  proposition  4.1.8  (1).  This  leads  to  the  following. 


jeojj  ^o  [M  match(||u0||, 
(case  ||e0||  of  (Hjc 


9  for  some  1  <  k  <  n  \\ek 


(ev-case) 


Note  that  ||case  eo  of  p\  =$■  ei  |  •  •  •  |  pn  =$■  en||  is 


case  ||e0||  of  (||pi||  =4-  ||ei| 


and  we  are  done. 


ei  ^ d  vi 


(Aa  :  y.ei )=—>£;  (Aa  :  7.U1)  Then  by  induction  hypothesis,  ||ei||  >o  ||ui||  is  derivable. 
Note  that  ||(Aa  :  7-ei)||  =  ||ei||  and  ||(Ao  :  7-'fi) ||  =  ||vi||.  Hence  we  are  done. 


ei  ^ d  (A a  :  7.17) 

e\[i]  ^>d  v\[a  i— >  i]  Then  by  induction  hypothesis,  ||ei||  ^->o  || (Act  :  7-Ui)||  =  ||t>i||  is  deriv¬ 
able.  Note  that  ||ei[i]||  =  ||ei||.  Also  ||ui[a  i— ►  i]||  =  ||ui||  by  Proposition  4.1.8  (1).  Hence,  we 
are  done. 


All  the  rest  of  the  cases  can  be  handled  similarly.  ■ 

Theorem  4.1.10  is  a  reconfirmation  that  type  indices  do  not  interact  with  program  evaluation. 
This  is  a  soundness  argument  in  the  sense  that  we  have  proven  that  index  erasure  is  sound  with 
respect  to  evaluation.  We  now  prove  that  index  erasure  is  also  complete  with  respect  to  evaluation, 
formulated  as  Theorem  4.1.12.  The  following  lemma  will  be  needed  in  its  proof. 
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Lemma  4.1.11  Given  a  value  v\  in  MLq  (C)  such  that  <f>\  ■  P  v\  :  Ila  :  7 .r  is  derivable,  r>i  must 
be  of  form  A  a  :  7.V2  for  some  value  v 2. 


Proof  This  follows  from  a  structural  induction  on  the  derivation  D  of  <f\T  P  vi  :  (Ila  :  7 .r). 

(f;  ■  P  ui  :  77  f>  \=  T\  =  Ila  :  7.T 
T>  = - - 

<f>\  ■  P  v\  :  Ila  :  7.T  Then  n  must  of  form  Ila  :  7-r(.  By  induction  hypothesis, 

ui  has  the  claimed  form. 

4>,  a  :  ■  \~  v  :  t 

V  = - - 

■  P  (Aa  :  'y.v)  :  (Ila  :  7  .r)  Then  77  is  A  a  :  7.7;,  and  we  are  done. 

Note  that  the  last  applied  rule  in  D  cannot  be  (ty-var).  Since  77  is  a  value,  no  other  rules  can  be 
the  last  applied  rule  in  V.  This  concludes  the  proof.  ■ 

Theorem  4.1.12  Given  </>;  •  he:r  derivable  inML^(C).  If  e°  =  ||e||  v°  is  derivable  for  some 
v°  in  MLq,  then  there  exists  v  in  ML^(C)  such  that  e  ^d  v  is  derivable  and  ||u||  =  v°. 


Proof  The  theorem  follows  from  a  structural  induction  on  the  derivation  of  e°  c— >0  v°  and  the 
derivation  V  of  f>;  ■  P  e  :  r,  lexicographically  ordered.  If  the  last  applied  rule  in  the  derivation  of 
(/>;  •  h  e  :  r  is 


4>\  ■  P  e  :  t'  (f\-  t'  =  t 
(>;  T  e  :  t 


(ty-eq) 


then  by  induction  hypothesis  e  ^->d  v  is  derivable  for  some  v  and  ||u||  =  v°.  This  allows  us  to 
assume  that  the  last  applied  rule  in  the  derivation  of  <f\  ■  P  e  :  r  is  not  (ty-eq)  in  the  rest  of  the 
proof.  We  present  several  cases. 


<f>]  •  I-  e0  :  t0  0;  ■  P  (pi  =>•  ei  |  •  •  •  |  pn  en)  :  r0  r 

■  P  (case  eo  of  (pi  =7>  ei  |  •  •  •  |  pn  =7-  en))  :  r  Then  the  derivation  of  e°  ^->0 

must  be  of  the  following  form. 


*d  Vo 


match (vqjP®)  =>  9q  for  some  1  <  k  <  n  e^[0o]  c— > d  v° 
(case  e°  of  ei  I  ' ' '  I  Pn  en)  ^ d  v° 


(ev-case) 


where  ||eo||  =  e{j,  ||pfe||  =  Pfc  and  ||efc||  =  e°  for  all  1  <  k  <  n.  Clearly,  we  also  have 


Pk  I  tq  t>  (<//;  TQ  \~  ek  :  t 

<t>‘,  ■  I-  Pk  =4-  efc  :  r0  =4-  r 


(ty-match) 


By  induction  hypothesis,  eo  c— uo  is  derivable  for  some  vq  and  ||t>o||  =  Vq.  Hence,  f>;  ■  P  vq  :  77 
is  derivable  by  Theorem  4.1.6.  By  Proposition  4.1.8  (6),  match(pfc,uo)  =$■  0  is  derivable  for 
some  9  and  ||0||  =  9q.  Note  e^[9f\  =  ||efc[0]||  by  Proposition  4.1.8  (1)  and  </>;  •  P  9  :  (</>';  T')  is 
derivable  by  Lemma  4.1.5.  This  yields  that  </>;  •  P  ek[9\  :  r  is  derivable  by  Lemma  4.1.4.  By 
induction  hypothesis,  e*,[0]  c-*o  v  is  derivable  for  some  v  and  ||e||  =  v°. 
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V  =- 


b,  a  :  7;  •  b  e\  :  r 


</>;  •  h  (Aa  :  7-ei)  :  (Ila  :  7. 17)  Hence  we  have  ||Aa  :  7.61 1|  =  ||ei|j  ^0  vu  for  some  vu.  By 

induction  hypothesis,  e\  c— >d  77  for  some  77  such  that  ||ui||  =  v°.  Hence  we  have  the  following. 

ei  ^ d  vi  ,  x 

t - 7 -  (ev-ilam) 

A  a  :  y.ei  c— >d  A  a  :  7.77 

=  u°,  and  this  concludes  the  case. 


V  =■ 


Note  || Aa  :  7.77 1|  = 

;  •  h  ei  :  na  :  7 .r  0  I—  i  :  7 


</>;  •  h  ei [i]  :  r[a  1— ►  i]  Then  we  have  ||ei[i]||  =  1 1 e  1 1 1  >0  uo  for  some  uo-  By  induction 

hypothesis,  e\  ^d  77  for  some  77.  By  Theorem  4.1.6,  (f>\  ■  h  v\  :  Ha  :  j.t  is  derivable.  Notice 
that  v\  is  of  form  A  a  :  7.V2  by  Lemma  4.1.11.  This  leads  to  the  following. 

ei  ^ d  vi 


eih  ^ d  V2[a 


(ev-iapp) 


Since  ||i>2[a  1— >  z]||  =  Ijt^H  =  ||vi||  =  v°,  we  are  done. 

All  other  cases  can  be  treated  similarly.  ■ 

Now  we  have  completely  justified  the  following  evaluation  strategy  for  ML^(C):  given  a  well- typed 
expression  e  in  MLq  (C),  we  can  erase  all  type  indices  in  e  to  obtain  a  well-typed  expression  ||e||  in 
MLo  and  then  evaluate  it  in  MLo-  By  Theorem  4.1.10  and  Theorem  4.1.12,  this  yields  the  expected 
result. 

We  are  now  at  the  stage  to  report  an  interesting  phenomenon  in  MLq  (C). 

Example  4.1.13  There  is  no  closed  expression  e  in  MLq(C)  of  type 


n m  :  nat.Hn  :  nat. int  1  i st (m  +  n )  — >  intlist(m) 

such  that  \\e\\(cons((0,nil}))  evaluates  to  a  value  in  MLo- 

Suppose  ||e||(cons((0,m/}))  evaluates  to  v.  Then  by  Theorem  4-1.12,  there  are  some  v\  of  type 
intlist(l)  and  77  of  type  intlist(O)  such  that 


e[l][0](cons[l]((0,  nil)))  77  and  e[0][l](coras[l]((0,m/)))  c— 772 


and  ||t7||  =  v  =  ||t;2||-  This  is  a  contradiction  since  v  cannot  be  a  list  of  length  both  zero  and  one. 

However,  this  does  not  mean  that  we  could  not  define  a  function  in  ML^C1)  to  be  of  the  type 
nm  :  nat.Hn  :  nat. intlist(m  +  n)  — >  intlist(m).  As  a  matter  of  fact,  the  following  function  is 
of  this  type. 

Am  :  nat.Xn  :  jraf.lam  x  :  intlist(m  +  ra). case  x  of  nil  =>  nil 

If  we  call  the  above  expression  e,  then  the  reader  can  readily  verify  that  e[l][0](cons[l]((0,mZ))) 
does  not  evaluates  to  any  value. 

It  turns  out  that  this  kind  of  types  can  also  significantly  complicate  the  constraints  generated 
during  an  elaboration  process  which  we  will  develop  in  the  next  section.  The  main  reason  lies  in 
that  the  existential  variable  elimination  approach  introduced  in  Subsection  4-2.6  does  not  cope  well 
with  the  constraints  produced  when  such  types  are  checked. 

Since  such  types  seem  to  have  little  practical  use,  we  intend  to  find  an  syntactic  approach  to 
disallowing  them.  This  will  be  a  future  research  topic. 
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It  is  a  straightforward  observation  on  the  typing  rules  for  MLjj^C1)  that  the  following  theorem 
holds. 

Theorem  4.1.14  MLq(C')  is  a  conservative  extension  of  MLq,  that  is,  given  T,e,v,r  in  MLo, 
•;  T  h  e  :  r  and  e  c— ^  v  are  derivable  in  MLq  (C)  if  and  only  ifT\~e:r  and  e  v  are  derivable 
in  MLo- 

Proof  The  “if”  part  immediately  follows  from  an  inspection  of  the  typing  and  evaluation  rules  for 
MLo,  which  are  all  allowed  in  ML^((7).  We  now  show  the  “only  if”  part.  Since  e  is  MLo,  neither 
rule  (ty-ilam)  nor  rule  (ty-iapp)  can  be  applied  in  the  derivation  of  *;T  b  e  :  r.  Therefore,  this 
derivation  can  easily  lead  to  a  derivation  of  T  b  e  :  r  in  MLo-  Similarly,  the  derivation  of  e  v 
can  readily  yield  a  derivation  of  e  v.  ■ 

The  novelty  of  our  approach  to  enriching  the  type  system  of  ML  with  dependent  types  is 
precisely  the  introduction  of  a  restricted  form  of  dependent  types,  where  type  index  objects  and 
language  expressions  are  separated.  This,  however,  does  not  prevent  us  from  reasoning  about  the 
values  of  expressions  in  the  type  system  because  we  can  introduce  singleton  types  to  relate  the 
value  of  an  expression  to  that  of  an  index.  For  example,  we  refine  the  type  int  into  infinitely  many 
singleton  types  int(i)  for  i  =  0,1,  —1,2,  —2, . . .,  each  of  which  contains  only  the  integer  i.  If  we 
can  type-check  that  an  expression  e  is  of  type  int(i),  then  we  know  that  the  run-time  value  of  e 
must  equal  i.  This,  for  instance,  allows  us  to  determine  at  compile-time  whether  the  value  of  an 
expression  of  type  int  is  within  certain  range.  Please  see  Section  9.2  for  more  details  on  this  issue. 

We  emphasize  that  both  MLo  and  ML^((7)  in  Theorem  4.1.14  are  explicitly  typed  internal 
languages,  and  hence  we  cannot  simply  conclude  that  if  the  programmer  does  not  index  any  types 
in  his  programs  then  these  programs  are  valid  for  ML^(C)  if  they  are  valid  for  MLo-  The  obvious 
reason  is  that  the  programmer  almost  always  writes  programs  in  an  external  language,  which 
may  not  be  fully  explicitly  typed.  Therefore,  these  programs  need  to  be  elaborated  into  the 
corresponding  explicitly  typed  ones  in  an  internal  language. 

In  order  to  guarantee  that  valid  programs  written  in  an  external  language  for  MLo  can  be 
successfully  elaborated  into  explicitly  typed  programs  in  ML^(C),  we  will  design  a  two  phase 
type-checking  algorithm  in  Chapter  6,  achieving  full  compatibility. 


4.2  Elaboration 

We  have  so  far  presented  an  explicitly  typed  language  MLq(C').  This  presentation  has  a  serious 
drawback  from  a  programmer’s  point  of  view:  one  would  quickly  get  overwhelmed  with  types  when 
programming  in  such  a  setting.  It  then  becomes  apparent  that  it  is  necessary  to  provide  an  external 
language  DMLo(C)  together  with  a  mapping  from  DMLo(C)  to  the  internal  language  ML^(C). 
This  mapping  is  called  elaboration.  Note  that  we  also  use  the  phrase  type-checking  to  mean 
elaboration,  sometimes. 


4.2.1  The  External  Language  DMLo(C')  for  MLq  (C) 

The  syntax  for  DMLq(C')  is  given  as  follows. 


60 


CHAPTER  4.  UNIVERSAL  DEPENDENT  TYPES 


patterns  p  ::=  x  \  c  \  c(p )  |  (}  |  (pi,P2) 
matches  ms  ::=  (p=>e)\(p=>e  \  7ns) 

expressions  e  ::=  x  |  c(e)  |  (}  |  (ei,e2) 

|  (case  e  of  ms)  |  (lam  axe)  |  (lam  x  :  r.e)  |  ei(e2) 

|  (let  x  =  e\  in  e2  end)  |  (fix  /  :  r.u)  |  A  a  :  y.e  |  (e  :  r) 

(e  :  r)  means  that  e  is  annotated  with  type  r.  Type  annotations  in  a  program  will  be  crucial  to 
elaboration.  Also,  the  need  for  A  a  :  y.e  is  explained  in  Section  8.3,  which  is  used  in  a  very  restricted 
way. 

Note  that  the  syntax  of  DMLo(C)  is  basically  the  syntax  of  MLo,  though  types  here  could  be 
dependent  types.  This  partially  attests  to  the  unobtrusiveness  of  our  enrichment.  The  type  erasure 
function  |  •  |  on  expressions  in  ML^C1)  is  defined  in  the  obvious  way.  Again  please  note  that  |  •  | 
is  different  from  the  index  erasure  function  ||  •  ||,  which  maps  an  MLq  (C)  expression  into  an  MLo 
one. 


4.2.2  Elaboration  as  Static  Semantics 

We  illustrate  some  intuition  behind  the  elaboration  rules  while  presenting  them.  Elaboration,  which 
incorporates  type  checking,  is  defined  via  two  mutually  recursive  judgments:  one  to  synthesize  a 
type  where  this  can  be  done  in  a  most  general  way,  and  one  to  check  a  term  against  a  type  where 
synthesis  is  not  possible.  The  synthesizing  judgement  has  the  form  </>;  T  b  e  |  r  =>■  e*  and  means 
that  e  elaborates  into  e*  with  type  r.  The  checking  judgement  has  the  form  (j>\  T  b  e  {  r  =7>  e*  and 
means  that  e  elaborates  into  e*  against  type  r.  In  general,  we  use  e,p,  ms  for  external  expressions, 
patterns  and  matches,  and  e*,p*,ms*  for  their  internal  counterparts. 

The  purpose  of  first  two  rules  is  to  eliminate  universal  quantifiers.  For  instance,  let  us  assume 
that  ei(e2)  is  in  the  code  and  a  type  of  form  Lla  :  y.r  is  synthesized  for  e\\  then  we  must  apply 
the  rule  (elab-pi-elim)  to  remove  the  quantifier  in  the  type;  we  continue  doing  so  until  a  major 
type  is  reached,  which  must  be  of  form  n  — ►  T2  (if  the  code  is  type-correct).  Note  that  the  actual 
index  i  is  not  locally  determined,  but  becomes  an  existential  variable  for  the  constraint  solver. 
The  rule  (elab-pi-intro-1)  is  simpler  since  we  check  against  a  given  dependent  functional  type. 
Of  course,  we  require  that  there  be  no  free  occurrences  of  a  in  T(x')  for  all  x  6  dom(T)  when 
(elab-pi-intro-1)  is  applied. 


6;  T  h  e  |  Lla  :  y.r  e*  (f>\~  i  :  y 
4>;  T  b  e  |  r[«  ^  i]  e*  [i] 

4>,  a  :  7;  T  h  e  j  r  e*  . 
>;  T  h  e  J,  Lla  :  7 .r  =>  (A a  :  y.e*) 


(elab-pi-elim) 


(elab-pi-intro-1) 


The  next  rule  is  for  lambda  abstraction,  which  checks  a  lam-expression  against  a  type.  The 
rule  for  the  fixed  point  operator  is  similar.  We  emphasize  that  we  never  synthesize  types  for  either 
lam  or  fix-expressions  (for  which  principal  types  do  not  exist  in  general). 

:  n  b  e  j  r2  =>-  e* 

— — — - — - - - —  (elab-lam) 

cp;  I  r  (lam  x.e)  J,  n  — >  T2  =>  (lam  x  :  n.e1) 
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The  next  rule  is  for  function  application,  where  the  interaction  between  the  two  kinds  of  judgments 
takes  place.  After  synthesizing  a  major  type  t\  — >  72  for  e\,  we  simply  check  e2  against  t\ — synthesis 
for  e2  is  unnecessary. 


4>;  r  h  ei  T  n  -»  r2  =>  e\  0;  T  h  e2  |  n  =>  e*2 
4>;T  \~  ei(e2)  T  r2  =>  e*(e|) 


(elab-app-up) 


We  maintain  the  invariant  that  the  shape  of  types  of  variables  in  the  context  is  always  determined, 
modulo  possible  index  constraints  which  may  need  to  be  solved.  This  means  that  with  the  rules 
above  we  can  already  check  all  normal  forms.  A  term  which  is  not  in  normal  form  will  most  often 
be  a  let-expression,  but  in  any  case  will  require  a  type  annotation,  as  illustrated  in  the  following 
one  of  two  rules  for  let-expressions. 


(/>',  T  b  ei  t  ti  e\  4>;  T,  x  :  n  b  e2  j  r2  =>•  e*2 
(f>;  T  h  let  x  =  e\  in  e2  end  I  t2  let  x  =  e\  in  e\  end 


(elab- let-down) 


Even  if  we  are  checking  against  a  type,  we  must  synthesize  the  type  of  ei.  If  e\  is  a  function 
or  fixpoint,  its  type  must  be  given,  in  practice  mostly  be  writing  let  x  :  r  =  e\  in  e2  end  which 
abbreviates  let  x  =  (e±  :  r)  in  e2  end.  The  following  rule  allows  us  to  take  advantage  of  such 
annotations. 


</>;  r  h  e  I  r  e* 

(f>\  T  b  (e  :  r)  |  r  e* 


(elab-anno-up) 


As  a  result,  the  only  types  appearing  in  realistic  programs  are  due  to  declarations  of  functions 
and  a  few  cases  of  polymorphic  instantiation.  The  latter  will  be  explained  later  in  Subsection  6.2.3. 

Moreover,  in  the  presence  of  existential  dependent  types,  which  will  be  introduced  in  Chapter  5, 
a  pure  ML  type  without  dependencies  obtained  in  the  first  phase  of  type-checking  is  assumed  if 
no  explicit  type  annotation  is  given.  This  makes  our  extension  truly  conservative  in  the  sense  that 
pure  ML  programs  will  work  exactly  as  before,  not  requiring  any  annotations. 

Elaboration  rules  for  patterns  are  particularly  simple,  due  to  the  constraint  nature  of  the  types 
for  constructors.  We  elaborate  a  pattern  p  against  a  type  r,  yielding  an  internal  pattern  p*  and 
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index  context  and  (ordinary)  context  F,  respectively.  This  is  written  as  p  j  r  =>•  in 

Figure  4.8.  This  judgment  is  used  in  the  rules  for  pattern  matching.  The  generated  index  context 
4>'  are  assumed  into  the  index  context  4>  while  elaborating  e  as  shown  in  the  rule  (elab-match) 
below.  For  constraint  satisfaction,  these  are  treated  as  hypotheses. 


P  I  D  =>  h  e  |  t2  e*  0Ft2:* 

far  \- (p  =>  e)  l  (ti  =7-  r2)  =7-  (p*  =>  e*) 


(elab-match) 


For  instance,  if  the  constructor  cons  is  of  type  r  =  Fla  :  nat. int  *  intlist(a)  — ►  intlist(o+  1), 
then  we  have  the  following. 


x  l  int  =7-  (x;  •;  x  :  int)  xs  j  intlist(a)  =$■  (xs\  •;  xs  :  intlist(a)) 
S{cons )  =  t  ( x ,  xs)  i  int  *  intlist(a)  =>■  ((x,  xs)',  •;  x  :  int,  xs  :  intlist(a)) 
cons({x,  xs))  |  intlist(n  +  1)  =7-  ( cons[a\((x ,  xs));  a  :  nat ,  a+l  =  n+l;x:  int,  xs  :  intlist(a)) 

Lemma  4.2.1  If  p  |r=t  {p*',4>]  T)  is  derivable,  then  p  =  ||p*||  and  p*  j.  r  D>  (^;T)  is  derivable. 


Proof  The  proof  proceeds  by  a  structural  induction  on  the  derivation  of  p  j  r  =7-  (p*;  0;  T).  We 
present  some  cases  as  follows. 

_Pi  I  n=>  ip\-,(t) i;Ti)  p2 1  r2  =4-  (^;</»2;r2) 

(P1,P2)  |ri*r24  ((Pl,^);^i,^;ri,r2)  By  induction  hypothesis,  for  i  =  1,2, 

Pi  =  ||p*||  and  p*  l  Ti  >  {(ffjTi)  are  derivable.  Therefore,  we  have  (pi,p2)  =  1 1  )  1 1  ’  and 

we  can  derive  (p*,p2)  |  ri  *  r2  >  (0i ,  02;  Fi , F2)  as  follows. 


Pi  I  n  >  (</>i;Fi)  p2  I  r2  >  (</>2;r2) 

(pi,p2)  I  n  *  r2  >  (0i,02;r1,r2) 


(elab-pat-prod) 


This  concludes  the  case. 


5(c)  =  Ilai  :  71 . . .  Flan  :  7 n.r  5(i)  p  j  r  =7>  (p*;  T) 

c{p)  |  6(j)  =7-  (c[ai]  . . .  [an](p*);  ai  :  71, . . . ,  an  :  jn,  i  =  j,  0;  T)  By  induction  hypothesis, 

p  =  ||p*  ||  and  p*  |  r  >  (</>;  T)  is  derivable.  Hence,  c(p)  =  ||c[ai] . . .  [an](p*)||  and  the  following 
is  derivable. 

5(c)  =  Ilai  :  7! . .  .Han  :  7„.(r  — »•  S(i))  p*  |  r  >(</>; T) 

— — - p —  - 7 - — —  (elab-pat-cons-w) 

c[aij  . . .  [anJ(p  )  |  d(j)  >  (ar  :  7ij...,an  :  7n,«  =  T) 


This  concludes  the  case. 

All  other  cases  are  straightforward.  ■ 

We  now  present  the  complete  list  of  elaboration  rules  for  ML^((7)  in  Figure  4.9  and  Figure  4.10. 
The  correctness  of  these  rules  are  justified  by  Theorem  4.2.2. 

There  is  a  certain  amount  of  nondeterminism  in  the  formulation  of  these  elaboration  rules. 
For  instance,  there  is  a  contention  between  the  rules  (elab-pi-intro-1)  and  (elab-pi-intro-2) 
when  both  of  them  are  applicable.  In  this  case,  we  always  choose  the  former  over  the  latter.  Also 
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0;  r  b  e  t  Ila  :  7 .r  =7>  e*  0  b  i  :  7 


(elab-pi-elim) 


(elab-pi-intro-2) 


0;  T  b  e  |  r[a  h  j]  7  e*[i] 

:  7;  T  b  e  |  r  e*  . 

— — —  — - 77 rv  (elab-pi-intro-1) 

0;  T  b  e  |  Ila  :  7 .r  =7  (Aa  :  7-e  ) 

_ 0,  a  :  7;  r  b  e  j  r  =»  e* _  ,  ,  ,  . 

0;  T  b  Aa  :  7-e  j  Ila  :  7.T  =7-  (Aa  :  7-e*) 

r(®)  =  t  0br[ctx] 

^rhitT^i  (elab-var-up) 

0;  r  b  X  T  Mi  =7>  e*  0  |=  m  =  H2  ,  ,  , 

- — — - : - - -  (elab-var- 

0;rbx|/i27>e*  v 

cS(c)  =  nai  :  71 . . .  IIan  :  7n.<50)  0  b  :  71  •  •  •  0  b  in  :  7 n 
0;T  b  c  t  5(*[ai, . . . ,  an  h->  h, .  ..in])  =7>  c[h }  ■  ■  ■  [in] 

0;  T  b  c  t  Mi  =>-  e*  0H/‘i=I'2m, 

0;  r  b  c  I  /x2  =>-  e*  v 


(elab-var-up) 


(elab-var-down) 


(elab-cons-wo-up) 


(elab-cons-wo-down) 


5(c)  =  Ilai  :  71  . .  .IIan  :  7n.r  — >  e>(i) 

0;  r  b  e  I  r[ai, . . . ,  an  h, . . .  in]  =7-  e* 

0  b  ii  :  71  •  •  •  0  b  in  :  7n 

0; T  b  c(e)  t  <K*[ai,  • .  ■  ,an  ii, .  ..*„])  =7>  c[ii]  . . .  [in](e*) 

0;  T  b  c(e)  0  (=  Mi  =  M2  ,  ,  , 

— —  .  -  (elab-cons 

0;  r  b  c(e)  1  M2  e* 

7..  T~i~~i _  /\  f  1  _ 1  A  (elab-unit-up) 


(elab-cons-w-up) 


(elab-cons-w-down) 


&;Tb  <>  T  1=>  <> 


(elab-unit-down) 


0;  r  b  ()  j.  1  =7  () 

0;  r  b  ei  |  Mi  ei  0;  r  b  e2  T  M2  e*2 
0;  r  b  (ei ,  e2)  T  Mi  *  M2  =*>  (e* ,  e^) 

0;  T  b  ei  |  ri  =7-  e*  0;  T  b  e2  |  r2  =7-  e£ 


(elab-prod-up) 


0;  r  b  (ei,  e2)  |ri*r27  (e*,e%) 


(elab-prod-down) 


Figure  4.9:  The  elaboration  rules  for  MLp(C)  (I) 
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P  In  =>  4>,  0';T,r'  I-  e  I  t2  =>•  e*  $  b  r2  :  * 

<t>\  T  I-  {p  =>  e)  |  (n  =*>  r2)  =*>  (p*  =>  e*) 

4>]  r  h  (p  =>  e)  |  (n  r2)  (p*  e*)  </>;  T  b  ms  j  (n  r2)  =>-  ms 


<f>;  T  b  (p  =>■  e  |  ms)  j  (ri  =£•  r2)  =4>  (p*  =>  e*  |  ms*) 

(j>\  T  b  e  |  n  =>  e*  <t>;  T  I-  ms  l  (ri  r2)  =^>  ms* 


(elab-match) 

(elab-matches) 


i>;  T  b  (case  e  of  ms)  |  r2  (case  e*  of  ms* 
4>]  T,  x  :  ri  b  e  i  t-2  =>  e* 


(elab-case) 


</>;  T  b  (lam  x.e)  j  r\  — >  r2  =^-  (lam  x  :  n.e*) 
0;I\xi  :  Ti,x  :  r  b  e  j  r2  e*  (fy,  T,  x\  :  n  b  xi  j  r  =>-  ej 


4>;  T  b  (lam  x  :  r.e)  j  ri  — ►  r2  =>■  (lam  xi  :  ri.let  x  =  ej  in  e*  end) 
T  b  ei  |  n  — ►  r2  =>-  e*  4>;  T  b  e2  j  ti  =^>  e2 


(elab-lam) 

(elab-lam-anno) 


^>;T  b  ei(e2)  T  t2  =>-  ef(e^) 

(/>;  T  h  ei(e2)  T  Pi  =>•  e*  cj)  |=  p1  =  p2 
</>;  T  b  ei(e2)  |  p2  =>  e* 

4>;  r  b  ei  t  n  =>  e\  0;  T,  x  :  t\  b  e2  |  r2  =>-  e£ 


(/>;  r  b  let  x  =  ei  in  e2  end  T  t2  =>-  let  x  =  e\in  e\  end 

4>]  r  b  ei  t  Ti  e\  <j>]  r,  x  :  n  b  e2  j  t2  =>-  e| 
f>;  r  b  let  x  =  ei  in  e2  end  I  t2  let  x  =  ej  in  e2  end 

(/);r,/:rbu|r=>u* 


(elab-app-up) 
(elab-app-down) 

(elab-let-up) 


</>;  T  b  (fix  /  :  t.u)  f  r  =J>  (fix  /  :  t.u*) 
^T ,  f  :  t  \-  u  l  t  =>  u*  (j>\  r,  x  :  r  b  x  J,  t'  =$■  e 


4>-,  r  b  (fix  /  :  t.u)  i  t'  =>  let  x  =  (fix  /  :  t.u*)  in  e*  end 

^rbe|r=>e* 


(elab- let-down) 
(elab-fix-up) 

(elab-fix-down) 


</>;  r  b  (e  :  r)  |  r  e: 

!>;  T  b  (e  :  r)  t  Pi  =>-  e*  <j)  |=  pi  =  p2 


i;rb(e:r)|/i2^e* 


(elab-anno-up) 

(elab-anno-down) 


Figure  4.10:  The  elaboration  rules  for  ML?((7)  (II) 
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notice  the  occurrences  of  major  types,  that  is  types  which  do  not  begin  with  a  II  quantifier,  in  the 

elaboration  rules.  The  use  of  major  types  is  mostly  a  pragmatic  strategy  which  aims  for  making  the 

elaboration  more  flexible.  After  introducing  the  existential  dependent  types  in  the  next  chapter, 
we  will  introduce  a  coercion  function  in  Subsection  5.2.1  to  replace  this  strategy. 

Theorem  4.2.2  We  have  the  following. 

1.  If  4>\T  b  e  |  r  =7>  e*  is  derivable,  then  0;T  b  e*  :  r  is  derivable  and  \e\  =  \e*\. 

2.  If  </>;  T  b  e  i  t  =7>  e*  is  derivable,  then  b  e*  :  r  is  derivable  and  |e*|  =  |e|. 


Proof  (1)  and  (2)  follow  straightforwardly  from  a  simultaneous  structural  induction  on  the 
derivations  V  of  f>;  T  b  e  |  t  e*  and  T  b  e  J,  r  e*.  We  present  a  few  cases. 


</>;  T  b  e  |  Ila  :  y.r  =7>  e*  f  1“  *  :  7 

</>;T  b  e  f  r[a  i — >•  z]  =>-  e*[i]  By  induction  hypothesis,  0;T  be*:  (Ila  :  q.r)  is 

derivable  and  |e*|  =  \e\.  This  leads  to  the  following. 

</>;  T  b  e*  :  (na  :  7 .r)  </>  b  i  :  7  . 

-  - r - -  (ty-iapp) 

cp;  I  b  e  |zj  :  r[a  1— ►  zj 

Clearly,  |e*[z]|  =  \e*\  =  \e\. 


(f]  T  b  x  t  tii  =4-  e*  <f)  \=  Hi  =  /z2 

T  b  x  i  H2  =>  e*  By  induction  hypothesis,  0;  T  be*  :  is  derivable  and 

e*\  =  x.  Hence  we  have  the  following. 


r  b  e*  :  m  cf>\=  m  =  H2 

</>;  r  b  e*  :  H2 


(ty-eq) 


4>;  r,  x  :  Ti  b  e  I  t2  e* 

</>;T  b  (lam  x.e )  j  t\  —*■  r2  =>•  (lam  x  :  ri.ef)  By  induction  hypothesis,  </>;  T,  x  :  t\  b  e*  : 
t2  is  derivable  and  |e*|  =  |e|.  This  yields  the  following. 


4>-  r,  x  :  T\  b  e*  :  r2 
4>;  T  b  (lam  x  :  77. e*)  :  ri  — ►  r2 


(ty-lam) 


Note  |lam  x  :  ri.e*|  =  lam  x.|e*|  =  lam  x.|e|  =  |lam  x.e|.  Hence,  we  are  done. 


<t>\  T,  xi  :  ri,  x  :  r  b  e  J.  r2  e*  0;  T,  xi  :  n  b  xi  J.  r  e\ 

<f\  T  b  (lam  x  :  T.e)  j  ri  — ►  r2  =7-  (lam  x\  :  ri.let  x  =  e\  in  e*  end)  By  induction  hypoth¬ 

esis,  both  </>;  T,  xi  :  ri,  x  :  r  b  e*  :  r  and  (j>;  T,  x\  :  ri  b  e\  :  r  are  derivable,  and  |e*|  =  |e|  and 
|ej|  =  xi .  This  leads  to  the  following. 


</>;  T,  xi  :  n  b  ej  :  r  T,  xi  :  n,  x  :  r  b  e* 
</>;  T,  xi  :  7~i  b  let  x  =  ej;  in  e*  end  :  r2 
0; T  b  (lam  x\  :  ri.let  x  =  ei  in  e*  end)  :  n 


:  t2 


(ty-let) 

—  (ty-lam) 

t2 
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Notice  that  we  have  the  following. 


lam  x'i  :  ri.let  x  =  e\  in  e*  end 


=  lam  xi.let  x  =  \e\\  in  |e*|  end 
=  lam  xi.let  x  =  x\  in  |e*|  end 
=  lam  x.|e*|  =  lam  x.\e\  =  I  lam  x.e 


This  concludes  the  case. 


V>;  T,  /  :  t  b  u  i  r  u*  </>;  T,  x  :  r  h  x  J,  t'  =>•  e* 

V>;  T  h  (fix  /  :  t.u)  \ ,  t'  =$■  let  x  =  (fix  /  :  t.u*)  in  e*  end  By  induction  hypothesis,  0;  T,  / 
r  b  u*  :  t  and  cf>;F,x  :  t  he*  :  t'  are  derivable.  This  leads  to  the  following. 


<frr,/  :  r  h  u*  :  r 
4>]  T  h  (fix  /  :  r.  u*)  :  r 


(ty-fix) 


6;  T,  x  :  t  h  e*  :  t' 


6;  T  h  let  x  =  (fix  /  :  t.u*)  in  e*  end  :  t' 


(ty-let) 


Also  by  induction  hypothesis,  |it*|  =  |rt|  and  x  =  \e*\.  This  yields  the  following. 


let  x 


(fix  /  :  t.u*)  in  e*  end 


=  let  x  =  (fix  f.\u*\)  in  \e*\  end 
=  let  x  =  (fix  f.\u\)  in  x  end 
=  (Ax  f-\u\)  =  | (fix  /.«)| 


Note  let  x  =  (fix  f.\u\)  in  x  end  =  (fix  f.\u\)  follows  from  Corollary  2.3.13. 


All  other  cases  can  be  treated  similarly.  ■ 

The  description  of  type  reconstruction  as  static  semantics  is  intuitively  appealing,  but  there 
is  still  a  gap  between  the  description  and  its  implementation.  There,  elaboration  rules  explicitly 
generate  constraints,  and  thus  reduce  dependent  type-checking  to  constraint  satisfaction.  This  is 
the  subject  of  the  next  subsection. 


4.2.3  Elaboration  as  Constraint  Generation 


Our  objective  is  to  turn  the  elaboration  rules  in  Figure  4.9  and  Figure  4.10  into  rules  which  generate 
constraints  immediately  when  applied.  For  this  purpose,  we  extend  the  language  for  type  index 
objects  as  follows. 


existential  variables 
index  objects 
existential  contexts 
existential  substitutions 


A 

i,j  ::=  ■  ■  ■  \  A 
V’  ::=  •IV’,  A:  7 
6  ::=  []  |  6[A  ^  i] 


Intuitively  speaking,  the  existential  variables  are  used  to  represent  unknown  type  indices  during 
elaboration  so  that  we  can  postpone  the  solutions  to  these  indices  until  we  have  enough  information 
on  them. 

We  now  list  all  the  constraint  generation  rules  in  Figure  4.11  and  Figure  4.12.  Note  that  we 
assume  A  is  not  declared  in  ^  when  when  we  expand  iptoip,A:  7.  Also  we  always  assume  that 
V>i  and  V’2  share  no  common  existential  variables  when  we  form  the  context  V’l,  V’2-  Also  notice  the 
occurrence  of  oN  in  the  rules  (constr-pi-intro-1)  and  (constr-pi-intro-2).  We  decorate  a  with 
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ip  to  prevent  any  existential  variable  declared  in  ip  from  unifying  with  an  index  i  in  which  there  are 
free  occurrences  of  aH  Note  eft  and  pft  stand  for  af,  ■  ■  ■  ,a%  and  af  :  71 ,a%  :  7„,  respectively, 
where  a  =  a\,...,an  and  (p  =  a\  :  71, , . . , an  :  7n.  If  a  proposition  P  is  also  declared  in  <p,  then 
label  all  the  free  index  variables  in  P  with  ip.  We  define  label(0)  as  follows. 

label(-)  =  0  label(^),  aft)  =  label(V>)  U  dom(V’) 


A  judgement  of  form  <p  \>  9  :  ip  can  be  derived  through  the  following  rules. 


b  </>[ictx]  (p\  b  i  :  7  A  0  label(V>i)  <pi ,  cp2  [A  1— >  i]  b  9  :  ip 

<P  b  []  :  •  (pi,  (p2  b  9[A  i]  :  A  :  7,  ip 

Also  we  use  3(V’).<h  for  3A\  :  71  . . .  3An  :  7„ . <I> ,  where  ip  =  A\  :  71, . . . ,  An  :  7 n. 

Given  an  index  context  (p  and  an  existential  context  ip ,  we  can  form  a  mixed  context  {(p  \  ip)  as 
follows. 

('  I  VO 
OHO 

(aft1  :  71,0  I  A  :  7,  VO 


=  ip 
= 

(  A  :  7,  (a^1  :  71  |  (p,  ip)  if  A  G  dom(V’i). 
1  aH  :  71,  (0  |  A  :  7,  VO  if  A  0  dom(V’i); 


Judgements  of  forms  {(p  \  ip)  b  i  :  7  and  ((p  \  ip)  \~  t  :  *  are  derived  as  usual,  that  is,  similar  to 
judgements  of  forms  (p  b  i  :  7. 


Proposition  4.2.3  Assume  that  (p  >  9  :  ip  is  derivable. 

1.  If  (cp  |  ip)  b  i  :  7  is  derivable  then  so  is  cp[9]  b  i[9]  :  7 [0]. 

2.  If  (cp  \  ip)  \~  t  :  *  is  derivable  then  so  is  cp[9]  b  r[0]  :  *. 

5.  If  (cp  |  ip)  b  r[ctx]  is  derivable  then  so  is  cp[9]  b  T[#][ctx]. 


Proof  These  immediately  follows  from  structural  induction  on  the  derivations  of  (cp  \  ip)  b  i  :  7, 
(cp  |  ip)  b  r  :  *,  and  (<p  \  ip)  b  T[ctx],  respectively.  ■ 

A  judgement  of  form  <p;T  b  e  |  r  =7>[V’]  $  basically  means  that  e  elaborates  into  some  expression 
with  a  synthesized  type  r  while  generating  the  constraint  $  in  which  all  existential  variables  are 
declared  in  ip.  Similarly,  a  judgement  of  form  cp]  T  b  e  j  r  =>[ip]  means  that  e  elaborates  into  some 
expression  against  a  given  type  r  while  generating  the  constraint  $  in  which  all  existential  variables 
are  declared  in  ip.  Therefore,  we  have  finally  turned  type-checking  into  constraint  satisfaction. 

Given  an  index  context  (p  and  a  constraint  formula  <h,  we  define  V(0).< h  as  follows. 

V(-).$  =  $  V(V>,a:7).$  =  V(V>).Va:7.$  V (<V>,  P).T  =  V(0).P  D  $ 


Proposition  4.2.4  Suppose  that  either  <p\  T  b  e  f  t  =>[V>]  $  or  ^;T  b  e  |  r  =7>[V’]  is  derivable. 
Then  (cp  \  ip)  b  T[ctx]  ,  (<p  \  ip)  \~  t  :  *  and  (V>  |  ip)  b  $  :  o  are  derivable. 
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0;  T  h  e  |  r  =00]  $  (0  |  0)  h  7  :  * 

ft  T  h  e  |  t  =00,  ^4  :  7]  ‘h 
ft  T  h  e  |  Ila  :  7  .r  =00]  4> 


0;  T  h  e  f  r[a  1— ►  A]  =00,  A  :  7]  $ 

0,  aft  :  7;  T  h  e[a  >—>■  aft]  j  r  =00]  $  (0  \  0)  I-  T[ctx] 


ft  T  h  Aa  :  7-e  j  Ila  :  7.T  =00]  V(a^  :  7).$ 
0,  :  7;  T  h  e  j  r  =00]  $  (0  \  0)  h  T[ctx] 


(constr-weak) 
(constr-pi-elim) 

(constr-pi-int  ro- 1 ) 


ft  T  h  e  |  Ila  :  7 .r  =00]  V(a^  :  7).$ 

T(x)  =  r  (0  |  0)  I"  r[ctx] 


(constr-pi-intro-2) 


ft  T  h  x  |  t  =00]  T 
0;  r  1-  x  t  mi  =002,  0i]  t  o  |  02)  1-  n-2 :  *  (0  |  02)  1-  r[ctx] 

0;r  1-  x  |  H2  =002]  3(00. m  =  P2 
S(c)  =  Ilai  :  71  . . .  IIan  :  7 n.5{i )  (0;  0)  h  Tfictx] 


</>;  r  h  c  t  5(*[ai, . . . ,  an  (-»•  2I1, . . . ,  An\)  =00,  Ai  :  71, . . . ,  An  :  7n]  T 

0;  T  h  c  |  <0u)  =002,  0i]  T 
(0  |  02)  I-  <0i2)  :  *  (0  |  02)  I-  T[ctx] 


( const  r-  var-  up ) 

(constr-var-down) 

(const  r-cons-wo-up) 


cl  S(i2)  =002]  3(^1). d(ii)  =  S(i2) 


(constr-cons-wo-down) 


5(c)  =  Ilai  :  71 . . .  II an  :  7 n.r  ->  e>(i) 

5>;  T  I-  e  |  r[ai, . . . ,  an  (-»•  ^4X, . . . ,  An]  =00,  20  :  71, . . . ,  An  :  7n]  $ 


( constr-cons- w-  up) 


ft  T  I-  c(e)  t  <K*[ai,  ,  an  ^  20, . . . ,  20])  =00,  20  :  71,  •  •  • ,  An  :  jn]  $ 

(const  r-cons-w-down) 


ft  T  I-  c(e)  t  <00)  =002, 0i]  4> 

(0  |  02)  1“  5(i2)  :  *  (0  j  02)  h  r[ctx] 


0;  r  I—  c(e)  I  S(i2)  =002]  3(00. 4>  A  <5(?'i)  =  <0*2) 
(0 1  0)  1-  r[ctx] 


0;  r  1-  <)  r  1  =00]  t 

I  0)  1-  r[ctx] 


(const  r-unit-up) 


0;  r  h  <)  1 1  =00]  t 
ft  r  h  a  t  n  =00]  $1  ft  r  h  e2  T  d 


(constr-unit-down) 

ft  $2 


ft  r  b  (ei,  e2)  T  n  *  r2  =00]  $1  A  <h2 
0;  r  1-  ei  I  Tj  =00]  $1  0;  £  h  e2  j  r2  =00]  $2 

0;  r  I—  (ei,  e2)  |  7  *  r2  =00]  $1  A  <h2 


(const  r-prod-up) 


(constr-prod-down) 


Figure  4.11:  The  constraint  generation  rules  for  ML^(C*)  (I) 
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0;r  h(p 


p|  ri  ^  (p*;  0i;  Ti)  0,^f;r,ri  he|r2  =>[i/j\  $ 
(0  |  ip)  h  ri  =^>  T2  :  *  (0  |  0)  ^  r[ctx] 

«^;  r  I-  (p  =>  e)  I  (n  r2)  =K0]  V(0f).3> 

=>■  e)  |  (ti  =4>  r2)  =00]  $1  0;  r  h  ms  |  (n  =4>  r2)  = 

0;  T  h  (p  e  |  ms)  j  (n  =4>  r2)  =00]  $i  A  <h2 
0;  T  h  e  t  ti  =00]  0;  T  h  ms  j  (n  =>-  r2)  =00] 

0;  T  h  (case  e  of  ms)  j  r2  =00]  ‘hi  A  <h2 
0;  T,  x  :  Ti  b  e  J,  r2  =00]  <f>  , 


(constr-match) 


(constr-matches) 


(constr-case) 


(constr-lam) 


0;  r  I-  (lam  x.e )  |  n  — >  r2  =00]  <b 

0;  r,  x  :  r  b  e  j  r2  =00]  $  0;  T,  x  :  T\  b  x  j  r  =00]  $1  . 

-  ( con 

0;  T  b  (lam  x  :  r.e)  J,  T\  — ►  r2  =00]  $  A  $i 

0;  T  b  ei  t  n  ->•  t-2  =00]  <f>i  0;  T  b  e2  j  n  =00]  $2  , 

-  ( con 

0;  T  b  ei(e2)  |  t2  =00]  $1  A  <b2 

0;  T  h  ei(e2)  T  Mi  =002,  0i]  $  (0  ]  02)  b  p2  :  *  01  1P2)  b  T[ctx] 
0;  T  b  ei(e2)  I  p2  =002]  3(0i)-$  A  pi  =  p2 
0;  r  h  ei  t  Ti  =00]  $1  0;  r,  X  :  n  1-  e2  |  r2  =00]  $2  , 

-  ( CO 

(j)-,  r  b  (let  x  =  ei  in  e2  end)  f  r2  =^>['0]  $1  A  <h2 

0;  r  I-  ei  t  Ti  =00]  $1  </>;  T,  x  :  ri  h  e2  J,  r2  =00]  $2  , 

-  ( com 

0;  T  b  (let  x  =  ei  in  e2  end)  j  r2  =00]  $1  A$2 

0;I\/  :  r  h  u  |  r  =00]  <f>  __  _ 


( const  r-  lam-  anno) 


(const  r-app- up) 


(constr-app-down) 


(constr-let-up) 


(constr-let-down) 


(constr- fix-up) 


0;  T  b  (fix  /  :  t.Vj)  |  r  =00]  ‘h 
0;  T,  /  :  r  b  u  [  r  =00]  $  0;  T,  x  :  r  b  x  J.  T\  =00]  $1  , 

0;  T  b  (fix  /  :  t.Vj)  j  Ti  =00]  $  A  <&i 

01,  02;  r  1-  e  I  r  =00]  $  01  A  r  :  * 

- ■ - — — ; - — - r  -  -  (constr-anno-up) 

01, 02;  T  b  (e  :  r)  |  r  =00]  <f> 

0;  T  b  (e  :  r)  |  Pi  =002, 0i]  T  (0  |  02)  b  P2  ■  *  (0  |  02)  b  T[ctx] 

0;  T  b  (e  :  t)  J.  p2  =002]  3(0i)-Pi  =  p2 


-  (constr-fix-down) 


(const  r-anno-down) 


Figure  4.12:  The  constraint  generation  rules  for  ML^(C)  (II) 
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Proof  This  simply  follows  from  a  simultaneous  structural  induction  on  the  derivations  of  <f\  T  b 
e  |  t  =>[if]  and  </>;  T  b  e  |  r  =^[-0]  $.  ■ 

Theorem  4.2.5  relates  the  constraint  generation  rules  to  the  elaboration  rules  in  Figure  4.9  and 
Figure  4.10,  justifying  the  correctness  of  these  constraint  generation  rules. 

Theorem  4.2.5  We  have  the  following. 

1.  Suppose  that  (f;T  b  e  j  r  <f>  is  derivable.  If  4>[9]  0  $[0]  is  provable  for  some  6  such  that 

(f  \>  6  \  if  is  derivable,  then  there  exists  e*  such  that  </>[$];  T[0]  b  e  f  t[9]  =$■  e*  is  derivable. 

2.  Suppose  that  (f;F  b  e  j  r  =>[if\  T  is  derivable.  If  <f[9\  0  $[0]  is  provable  for  some  6  such  that 

<f  D>  6  :  if  is  derivable,  then  there  exists  e*  such  that  </>[$];  r[$]  \~  e  [  t[0\  =>•  e*  is  derivable. 


Proof  (1)  and  (2)  follows  from  a  simultaneous  structural  induction  on  the  derivations  T>  of 
T  b  e  |  t  =>[if\  and  <f\  T  b  e  j  r  =>[if]  <f>.  We  present  several  cases  as  follows. 


<f,  :  7;  T  b  e  j  r  =>[if\  $ 

<f;T  b  e  |  Ila  :  7 .r  =^]  V(ab  :  7).$  Note  that  (V(o^  :  7) .T>) [6*]  =  V(ab  :  7[0]).$[0]  since 

cf  \>  8  :  if  is  derivable.  The  derivation  of  <f[9\  |=  V(ab  :  7[0]).<b[0]  must  be  of  the  following 
form. 

#?],qb:7[g]  |=  T>[6>] 

m  hV(a^:7[0]).$[0] 


By  induction  hypothesis,  <f[0],a^  :  7(0];  T[0]  b  e  j  t[0]  =4-  e*  is  derivable, 
following. 


(f[9\,a^  :7[g];r[g]  be  =»  e* 
<f[6];T[6]  b  e  |  nab  :  7[0].r[0]  =7  e* 


(elab-pi-int  ro- 1 ) 


This  leads  to  the 


Note  that  n(a^  :  7[0]).t[0]  is  (H(a^  :  7 ).t)[0],  and  we  are  done. 


(f\ T  b  e\  |  n  =7[0]  4>i  0;  T  b  e2  T  T2  =4>[V’]  $2 

(f;T  b  (61,62)  T  Ti  *  T2  =>[V’]  $1  A  $2  Then  there  exists  0  such  that  (f  (=  (4>i  A 

4*2)  [0]  is  derivable.  This  implies  that  both  cf  |=  $i[0]  and  cf  |=  T>2  [^?]  are  derivable.  By 
induction  hypothesis,  for  i  =  1,2,  </>[0];r[0]  b  e*  |  t% [6\  =7  e*  are  derivable  for  some  e*.  This 
leads  to  the  following. 


(f[0}- r[0]  b  ei  T  Ti[fl]  g-  e|  0[6>];T[g]  b  e2  T  t2[0\  g-  e^ 
0[0];F[0]  be|  ri[6»i]  *t2[02]  =7  (e*,e£) 


(elab-prod-up) 


Note  that  (ri  *  77)  \9]  =  ri  \9]  *  77  [0] .  Hence  we  are  done. 


^rbeotro  =7[V>]  0  r  b  ms  |  (r0  =7  r)  =>[if]  <f>2 

<f;  T  b  (case  eo  of  ms)  j  r  =^[-0]  4>i  A  $2  Then  <f[9]  \=  (4>iA4>2)[02]  is  deriv¬ 

able  for  some  9  such  that  0  D>  0  :  if  holds.  This  implies  cf  (=  4>i[0]  and  (f  |=  4>2[0]  are  derivable. 
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By  induction  hypothesis,  4>[9];  T[0]  b  eo  T  to[0]  =>  and  00 ];  r[0]  b  ms  j  to[0] 
are  derivable  for  some  ej  and  ms*.  This  leads  to  the  following. 

;  r[0]  b  e0  T  ro[0]  =>-  e*  ms  J.  (ro[0]  r[0])  ms* 

(case  e*  of  ms*) 


];T[0]  b  (case  eo  of  ms)  j  r[0] 
Hence  we  are  done. 


t[0] 

(elab-case) 


ms 


0  r  I-  ei  t  Ti  -*■  r2  =00  $1  0  T  b  e2  j  n  =00  <f>2 

0Tb  ei(e2)  T  r2  =^['0]  Ti  A  <h2  Then  00]  |=  ($i  A  <b2)[0]  is  deriv¬ 

able  for  some  0  such  that  <(>  D>  0  :  0  is  derivable.  Hence,  00]  |=  $00]  is  derivable,  and  this 
yields  that  00];T[0]  b  e\  |  t\ [0]  — »  r2[0]  0  is  derivable  for  some  e\.  Also  by  induction 

hypothesis,  0[0] ;  T [0]  b  e2  j  ri[0]  e2  is  derivable  for  some  e2  since  (j)[6\  |=  $2[0]  is  derivable. 
This  yields  the  following. 


0[6>];  T[0]  b  ei  t  n[0]  ->  t2\0\  =>  0  0[0];  T[0]  b  e2  j  T00]  e*2 

0[0] 5  T[0]  b  ei(e2)  t  r2[0]  e|(eJ|) 


(elab-app-up) 


Hence  we  are  done. 

0Tb  ei(e2)  \  m  =^[02, 0i]  $  (<t>  |  0)  b  02  '■  *  (4>  I  0)  b  T[ctx] 

0  r  b  ei(e2)  j  /U2  =002]  3(0).$  A  /ii  =  /^2  Then  the  following 

002]  |=  (3(0).$  A  /ii  =  /i2)  [02] 

is  derivable  for  some  02  such  that  <(>  [>  0  :  0 2  holds.  Note  that 

(3(0).$  A  m  =  ^2)[02]  =  3(0). $[02]  A  m [02]  =  /U.2 [02] , 

and  therefore  0[02]  |=  3(0).$[02]  A^i[02]  =  ^i2[02]  is  derivable.  This  means  that  (002]  \= 
<h[02]A/ui[02]  =  /-i2 [02] )  [0i]  is  derivable  for  some  0\  such  that  0[02]  b  0i  :  0  holds.  This  implies 
that  4>  t>  02U0i  :  0,  0  is  also  derivable.  By  induction  hypothesis,  0[0] ;  T [0]  b  ei(e2)  |  T2[0]  =>• 
e*  is  derivable  for  0  =  02U0i.  Since  both  0  |  0)  b  T[ctx]  and  (</>  |  0)  b  r2  :  = 1=  are  derivable, 
we  have  0[0]  =  002][0i]  =  0[02] ,  r[0]  =  r[02][0i]  =  T[02],  and  r2[0]  =  r2[02][0i]  =  r2[02]. 
Therefore,  002];T[02]  b  ei(e2)  T  t2[02]  =$■  e*  is  derivable. 

0 T  b  ei  T  ri  =00  $1  (j)-,T,x  :t ibe2|  r2  =00  $2 

0;  T  b  (let  x  =  e\  in  e2  end)  J,  r2  00  $1  A  $2  Then  0[0]  j=  ($1  A$2)[0]  is  derivable 
for  some  0  such  that  0  O  0  :  -02  holds.  Clearly,  ($1  A  $2)[0]  =  $i[0]  A  $2[0],  and  therefore, 
both  00]  |=  $00]  and  00]  b  $2(0]  are  derivable.  By  induction  hypothesis,  both  0[0] ; T[0]  b 
e\  T  ri[0]  =>  0  and  0[0] ; T[0] , a:  :  700]  b  e2  j  r2[0]  e2  are  derivable.  This  leads  to  the 
following. 

0[0] ;  T[0]  b  ei  T  n[0]  0  00];T[0],x  :  700]  b  e2  I  r2[0]  0  e*2  ^  down~) 

0[0] ;  T[0]  b  let  x  =  e\  in  e2  end  |  r2[0]  =^-  let  x  =  e\  in  e2  end 


Hence  we  are  done. 
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(p;  T  P  e  [  t  =7>[0]  $  (f>\-  t  :  * 

<j>)  T  1-  (e  :  r)  |  r  =>[-0]  T  Then  0[0]  j=  T[0]  is  derivable  for  some  6*  such  that  0  \>  0  : 

0  holds.  By  induction  hypothesis,  0[0];T[0]  P  e  f  t[6]  =7-  e*  is  derivable  for  some  e*.  Since  r 
cannot  contain  any  existential  variables,  t\9\  =  r.  This  leads  to  the  following. 


^];T[g]he|r=>e* 
0[0];T[0]  h  (e  :  r)  |  r  e* 


(elab-anno-up) 


All  other  cases  can  be  handled  similarly.  ■ 

Given  a  closed  expression  e  in  the  external  language  DMLo(C'),  we  try  to  derive  a  judgement 
of  form  h  e  j  r  4^]  $.  This  can  succeed  if  there  are  enough  type  annotations  in  e.  By 
Theorem  4.2.5,  e  is  typable  if  and  only  if  •  |=  3(-0).T  is  provable.  In  this  way,  type-checking  in 
ML^(C)  is  reduced  to  constraint  satisfaction. 

There  is  still  some  indeterminacy  in  the  constraint  generation  rules,  which  has  to  be  handled  in 
an  implementation.  For  instance,  if  both  of  the  rules  (constr-pi-intro-1)  and  (constr-pi-intro-2) 
are  applicable,  it  must  be  decided  which  one  is  to  be  applied.  We  will  explain  some  of  these  issues 
in  Chapter  8. 


4.2.4  Some  Informal  Explanation  on  Constraint  Generation  Rules 

We  first  explain  why  the  rule  (constr-weak)  is  needed.  Note  that  in  the  following  rule 


0;  r  P  e\  t  n  =>[-0]  4>1  0;  T  P  e2  |  T2  =K0]  $2 
0;  T  P  (ei,  e2)  T  ri  *  72  =K0]  Ti  A  T2 


(const  r-prod-up) 


the  two  premises  must  have  the  same  existential  variable  declaration  ip.  However,  it  is  most  likely 
that  (p\T  \-  e\  ]  T\  =>[-0i]  $i  and  0;T  P  e\  f  ri  =7[-02]  Ti  are  derived  for  different  (pi  and  02.  In 
order  to  obtain  the  same  (p,  the  rule  (constr-weak)  needs  to  be  applied.  Now  the  question  is  why 
we  do  not  replace  the  rule  (constr-prod-up)  with  the  following. 

0;  r  1-  ei  T  n  =>[ipi]  4q  0;  T  I-  e2  |  D  =K02]  4>2 
0;T  P  (ei,e2)  Thu2  =K0i,02]  $i  A  4>2 


Unfortunately,  this  replacement  can  readily  invalidate  Proposition  4.2.4,  and  thus  breaks  down  the 
proof  of  Theorem  4.2.5.  We  present  such  an  example.  Suppose  we  try  to  derive  the  following  for 
some  T. 


a  :  7;  x  :  <5(Ai),  y  :  5(A2)  P  let  z  =  ( x ,  y)  in  z  end  j  5(a)  *  5(a)  =>[Ai  :  7,  A2  :  7]  <t> 
Hence,  we  need  to  derive  the  following  for  some  r  and  To- 

a-.'y-x  :  5(Ai),y  :  5(A2)  P  (x,y)  |  r  =>[Ai  :  7,  A2  :  7]  T0 
However,  it  is  impossible  to  find  -01  and  02  such  that  ipi,  tp2  =  A\  :  7,  A2  :  7  and  both 


a  :  j;x  :  5(A^,y  :  5(A2)  P  x  f  n  =>[ipi\  Ti  and  a  :  7;  x  :  5(Ai),y  :  5(A2)  P  y  f  r2  =>[ip2\  T2 
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are  derivable  for  some  n,$i  and  72,  $2,  respectively.  For  instance,  if  ipi  =  A\  :  7,  then  the 
judgement  a  :  7;x  :  5(Ai),y  :  5(A-2)  \~  x  ]  t\  =7 [g^i]  $1  is  ill-formed  since  A-j  is  not  declared 
anywhere. 

We  now  briefly  mention  how  these  constraint  generation  rules  are  implemented.  We  associate  a 
function  up  with  the  judgements  of  form  </>;  T  b  e  f  r  =^[ip]  4>,  which,  when  given  a  triple  ( q i>,  T,  e), 
returns  a  triple  (r,  ip,  <b) .  Similarly,  we  associate  a  function  down  with  the  judgements  of  form  (p;  T  b 
e  |  r  =^[V’]  4>,  which  returns  $  when  given  (c />,  T,  e,  pj,  r).  There  are  also  occasions  where  we  need  a 
variant  up'  of  up  which  returns  a  pair  (r,  $)  when  given  a  quadruple  (^>,  T,  e,  ip).  For  instance,  when 
computing  doivn((p,  T,  let  x  =  e\  in  end,  ip,  72),  we  need  to  compute  up' (cp,  T,  e\ ,ip)  to  get  a  pair 
(ti,  d>i)  and  then  compute  doiun(cp,  (T,  x  :  ri),  e 2,  ip,  T2)  to  get  d>2.  The  result  of  down((j),  T,  let  x  = 
e\  in  e2  end,'0,r2)  is  then  $1  A  $2.  The  actual  implementation  simply  follows  the  constraint 
generation  rules,  and  therefore  we  omit  the  further  details. 

4.2.5  An  Example  on  Elaboration 

We  now  present  a  simple  example  in  full  details  to  illustrate  how  the  constraint  generation  rules 
in  Figure  4.11  and  Figure  4.12  are  applied.  Unlike  in  MLo,  the  type-checking  is  rather  involved 
in  MLj^C),  and  therefore  we  strongly  recommend  that  the  reader  follow  through  these  details 
carefully.  This  will  be  especially  helpful  if  the  reader  intends  to  understand  how  type-checking 
is  performed  for  existential  dependent  types,  which  is  a  highly  complicated  subject  in  the  next 
chapter. 

The  following  is  basically  the  auxiliary  tail-recursive  function  in  the  body  of  the  reverse  function 
in  Figure  1.1,  but  we  have  replaced  the  polymorphic  type  Ja  list  with  the  monomorphic  type 
intlist.  We  will  not  introduce  polymorphic  types  until  Chapter  6. 

fun  rev(nil,  ys)  =  ys 

I  rev(x: :xs,  ys)  =  rev(xs,  x: :ys) 

where  rev  <|  -[m:nat]-  {n:nat]-  intlist  (m)  *  intlist  (n)  ->  intlist  (m+n) 

This  code  corresponds  to  the  following  expression  in  the  formal  external  language  DMLo(C'), 
fix  rev  :  (Ilm  :  nat.TIn  :  nat. intlist(m)  *  intlist(n)  — ►  intlist (m  +  n)).body 


where 


body  =  lam  pair. case  pair  of  ( nil,ys )  =>  ys  \  ( cons((x,xs)),ys )  =>  rev((xs,  cons((x,ys)))) 


For  the  sake  of  simplicity,  we  will  omit  the  parts  of  a  constraint  generation  rule  that  do  not  generate 
constraints  when  we  write  out  constraint  generation  rules  in  the  following  presentation. 

Let  revCode  be  the  above  DMLo(C')  expression.  We  aim  for  constructing  a  derivation  of  the 
following  judgement 

•;  •  h  revCode  |  r  =7>[-]  4>o 

for  some  r  and  4>q.  Hence,  the  derivation  must  be  of  the  following  form 


•;  rev  :  r  h  body  j  r  =>[•]  $0 
•;  •  h  revCode  |  r  =7>[-]  $0 


( const  r- fix- up) 
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r  =  Ilm  :  nat.Hn  :  nat. intlist(m)  *  intlist(n)  — >  intlist(m  +  n). 
Then  we  should  have  a  derivation  of  the  following  form  for  some  $1, 


m  :  nat,  n  :  nat ;  rev  :  r  b  body  j  y  =^[-]  4>i 
m  :  nat,  rev  :  r  b  body  [  Iln  :  nat.y  =>[•]  Vn  :  nat.<k\ 
•;  rev  :  r  b  body  j  r  =>•[•]  Vm  :  nat.Vn  :  nat.&i 


(constr-pi-intro-2) 

(constr-pi-intro-2) 


where  4>o  =  Vm  :  nat.Vn  :  naf.Ti  and  y  =  intlist(m)  *  intlist(n)  — >  intlist(m  +  n).  Then  we 
should  reach  a  derivation  of  the  following  form, 


</>;  T  b  case  pair  of  ms  j  intlist(m  +  n)  =>[•]  4>i 
m  :  nat ,  n  :  nat ;  rev  :  r  b  body  |  /r  =K-]  $1 


(constr-lam) 


where  <f>  =  m  :  nat,n  :  nat,  V  =  rev  :  r,pair  :  intlist(m)  *  intlist(n),  and  ms  is 
(nil,ys)  =$■  ys  \  (cons({x,  xs)),ys)  =>■  rev((xs,  cons({x,ys)))) 


Then  we  should  reach  a  derivation  of  the  following  form  for  some  13,  $2  and  $3  such  that  4>i  = 
<f>2  A  $3. 


4>;  T  b  pair  |  T3  =>•[•]  $2  4>'i  T  b  ms  |  (r3  =$■  intlist(m  +  n))  =>[•]  <£3 

^;fb  case  pair  of  ms  |  intlist(m  +  n)  =>[•]  $2  A  $3 


(constr-case) 


Clearly,  we  have  the  following  derivation  for  73  =  intlist(m)  *  intlist(n)  and  d>2  =  T. 


T  (pair)  =  T3 
i;T  b  pair  f  73  =>[•]  d>2 


( const  r-  var-  up ) 


Then  we  should  reach  a  derivation  of  the  following  form  for  $3  =  $4  A  <£5, 

_ Th  H>2 _ 

4>;  T  b  ms  |  (intlist(m)  *  intlist(n)  =>  intlist(m  +  n))  =>[•]  $4  A  4>5 


(constr-matches) 


where  V\  is  a  derivation  of 

4>;  T  b  (nil,  ys)  =$■  ys  j  (intlist(m)  *  intlist(n)  intlist(m  +  n))  =>[•]  $4 
and  T>2  is  a  derivation  of 

4>;  T  b  (cons((x,xs)),ys)  =$■  ys  |  (intlist(m)  *  intlist(n)  =$■  intlist(m  +  n))  =>■[•]  $5 
Clearly,  T>  1  is  of  the  following  form  for  some  p\ ,  <p  1  and  T 1 , 


(nil,  ys)  |  t3  >  (gij_^i|Ti)  4>,  <fti;  T,  T 1  b  ys  j  r4  =>[■]  <f>4 
</>;  T  b  (nil,  ys)  =>  ys  j  r3  r4  =>[•]  <f>4 


(constr-match) 
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where  74  =  intlist(m  +  n).  Notice  that  we  have  the  following  derivation  for  p\  =  (nil,ys) ,  (f>  1  = 
0  =  777.  and  Ti  =  ys  :  intlist(n). 

S(nil )  =  intlist(O) 

nil  [  intlist(m)  >  (nil]  0  =  m;  •)  ys  j  intlist(n)  >  ( ys ;  •;  ys  :  intlist(n)) 

(nil,  ys)  i  t3  >  (pi;  (pi]Ti) 


Hence  we  have  the  following  derivation  for  $4  =  V(0i).intlist(n)  =  intlist(m  +  n). 


Fi(ys)  =  intlist(n) 

4>,  ^>i;r,  Ti  b  ys  |  intlist(n)  =>[•]  T 
<j),  <j)\]T,  ri  b  ys  |  74  =>•[•]  intlist(n)  =  intlist(m  +  n) 
0;  T  b  (nil,  ys)  =>  ys  j  73  r4  =>[■}  <f>4 


(constr-var-down) 

(constr-match) 


Now  let  us  turn  our  attention  to  V 2.  Clearly,  £>2  is  of  the  following  form  for  some  p2,  4> 2  and  r2, 

(cons((x,xs)),ys)  |r3t>  (p2;</>2;T2)  (p,(p2]T  ,T2  b  rev((xs,  cons((x,ys))))  |  r4  =>[•]  $5 

<^;Fb  (cons((x,xs)),ys)  =>  ys  |  (73  =>-  r4)  =*>[•]  $5 

where  <£5  =  V(02)  •‘^>5-  Notice  that  we  have  the  following  derivation  T> 3 


x  |  int  >  (x\  •;  x  :  int)  xs  j  intlist(a)  >  (xs;  -;xs  :  intlist(a)) 
S(co7is)  =  Tcons  (x,xs)  >  ((x,xs)]-]x  :  int,xs  :  intlist(a)) 

cons((x,  xs))  i  intlist(m)  >  (cons[a\((x,  xs))]  a  :  nat,  a  +  1  =  m;  x  :  int,  xs  :  intlist(a)) 

where  TCOns  =  Ida  :  nat. int  *  intlist  (a)  — ►  intlist(a  +  1).  This  leads  to  the  derivation  below 
for  P2  =  (cons[a\((x,xs)),ys),4> 2  =  a  :  nat,  a  +  1  =  m  and  r2  =  x  :  int,  xs  :  intlist(a),  ys  : 
intlist  (n). 


£>3  ys  |  intlist(n)  >  (ys]  •;  ys  :  intlist(n))  ,  x 
- - - — - — - — - - - — -  (elab-pat-prod) 

(cons((x,xs)),ys)  |  r3  D>  (p2;02;r2) 

We  now  have  the  task  to  construct  a  derivation  of  the  following  form  for  some  t\,  72  and  ip, 

4>,(j)2]T,T2  b  rev  t  n  -»  r2  =>[ip\  d>6  </>,  (p2]T,T2  b  (co7is((x,xs)),ys)  j  r2  =>[ip\  $7 

02;  r,  r2  b  rev((xs,cons((x,ys))))  |  n  =>[ip]  d>6  A  d>7 

<^,^2;r,r2  b  rev((xs,cons((x,ys))))  j  r4  =>[•]  d>'5  (constr  app  down) 

Obviously,  we  have  the  following  derivation  for 

n  =  intlist  (M)  *  int  list  (iV)  r2  =  intlist  (M  +  IV)  ip  =  M  :  nat,N  :  nat  d>6  =  T. 

<p,  (/>2;T,r2  b  rev  |  Tim  :  7iat.IIn  :  nat. intlist(m)  *  intlist(n)  — >  intlist(m  +  n)  =^[-]  T 
(j),  4>2]  T,  T2  b  rev  t  Ha  :  nat. intlist(M)  *  intlist(n)  — ■>  intlist(M  +  n)  =^[M  :  nat]  T 

4>,  4>2]  r,  r2  b  rev  T  n  ->  r2  =>[V>]  $6 
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Then  we  need  to  construct  a  derivation  of  the  following  form, 

</>,  ^2;r,r2  bj  intlist(M)  =>[^]  ^8  <t>,  ^>2;r,r2  I-  cons((x,ys))  I  int  list  (AT)  =^[V>]  $9 

<$>,  4>2\ r,  r2  1-  (xs,  cons((x ,  ys)))  j  n  =>[y>]  $8  A  <f>9 


where  $7  =  $8  A  $9. 

Clearly,  we  have  the  following  derivation  for  $8  =  intlist(o)  =  intlist(M). 


T2(xs)  =  intlist(ra) 

4>,  (j>2‘,  T,  r2  b  xs  t  intlist(n)  =>[ip]  T 
(j),  </>2;T,T2  h  xs  |  intlist(M)  =>[$\  $8 


(constr-var-up) 

( const  r-  var-  down) 


Let  V4  be  following  derivation, 


r2(s)  =  int 


(j),  <^>2;  r,  T2  b  x  |  int  =>[ip,  L  :  nat ]  T 
!>,  4>2',  T,  T2  b  x  l  int  L  :  nat]  T  A  int  =  int 


(constr-var-up) 


(constr-var-down) 


and  D5  be  the  following  derivation. 

P2(ys)  =  intlist  (n) 

- — — - r - - - - —  (constr-var-up) 

4>,  02;T,r2  h  ys  t  intlist(n)  =>[ip,L  :  nat  T 

- - — — — - - - - 77 — - - - ; — 7 - 77—  (constr-var-down) 

(j>,  02 ;  r,  r2  b  ys  l  intlist(L)  :  nat]  T  A  intlist(n)  =  intlist(L) 


Therefore,  we  have  the  following  derivation 

_ D4  £>5 _ 

S(cons)  =  Tcons  (f>,  02;  r,  T2  b  (x,ys)  |  int  *  int  list  (L) 


L  :  nat]  <&io 


(j>,  02;  T,  T2  b  cons{(x ,  ys))  f  intlist(L  +  1)  =>[ip,  L  :  nat]  T  A  $10 


(constr-prod-down) 

(constr-cons-w-up) 


<f>,  ^2;T,T2  b  cons({x,  ys))  j  int  list  (JV) 


(const  r-app-down) 


for  <hg  =  3(L  :  nat). T  A  $10  A  intlist(L  +  1)  =  intlist(iV),  where  <Lio  =  T  A  int  =  int  A  T  A 
intlist(n)  =  intlist(L).  So  far  we  have  constructed  a  derivation  of 


4>,  4>2]  r,  r2  b  rev((xs,  cons((x,  ys))))  |  r2  =>[V>]  <f>6  A  <f>7, 
which  then  leads  to  the  following  for  =  □(■0) .<T>6  A  <h7  A  intlist (M  +  N)  =  intlist(m  +  n). 
0,</>2;r,T2  b  rev((xs,cons((x,ys))))  |  r2  ^[ip]  <f>6  A  $7 

- ; - 77 - - - 77 - : -  (constr-app-down) 

^,02;T,r2  b  rev((xs,cons((x,ys))))  |  r4  =►[■]  $5 

We  have  finally  finished  the  construction  of  a  derivation  of  •;  •  b  revCode  |  r  =>•[•]  $0  for 

$0  =  Vm  :  nat.Vn  :  nat.&i  =  Vm  :  nat.Vn  :  nat.<h2  A  <£3  =  Vm  :  nat.Vn  :  nat.T  A  $4  A  $5 

=  Vm  :  nat.Vn  :  nat. T  A  (0  =  m  D  intlist(n)  =  intlist(m  +  n))  A  $5 

$5  =  Va  :  nat.a  +  1  =  m  D  $5 

=  Va  :  nat.a  +  1  =  m  D  3M  :  nat.  3  AT  :  nat. $6  A  $7  A  intlist(M  +  iV)  =  intlist(m  +  n) 

=  Va  :  nat.a  +  1  =  m  D  3M  :  nat. 3N  :  nat. T  A  <h7  A  intlist(M  +  AT)  =  intlist(m  +  n) 

$7  =  ‘hs  A  $9  = 

=  3(L  :  nat). intlist(a)  =  intlist (M)  A  T  A  <hio  A  intlist(L  +  1)  =  intlist(A/") 

$10  =  T  A  int  =  int  A  T  A  intlist(n)  =  intlist(L) 
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If  we  replace  5(i)  =  6(j)  with  i  =  j  and  remove  all  T,  then  $o  can  be  reduced  to  the  following. 

Vm  :  nat.\/n  :  nat. 

(0  =  m  D  n  =  m  +  n)  A 
Va  :  nat. a  +  1  =  m  D  A 
3M  :  nat.BN  :  nat. 

(3 (L  :  nat). a  =  MAn  =  LAL  +  l  =  N)AM  +  N  =  m  +  n 

If  we  eliminate  all  the  existential  quantifiers  in  4>o  by  substituting  n  for  L,  a  for  M  and  n  +  1  for 
N,  we  obtain  the  following  constraint. 

Vm  :  nat.Vn  :  nat. 

(0  =  m  D  n  =  m  +  n)  A 

Va  :  nat. a  +  1  =  m  Z4  {a  =  a  An  =  n  An  +  1  =  n  +  1  A  a  +  (n  +  T)  =  m  +  n) 

The  validity  of  the  constraint  can  be  readily  verified.  Therefore  |=  $  is  derivable,  implying  that 
revCode  is  well-typed. 

The  elimination  of  existential  quantifiers  is  crucial  to  simplifying  constraints,  and  therefore 
crucial  to  the  practicality  of  our  approach.  We  address  this  issue  in  the  next  subsection. 

4.2.6  Elimination  of  Existential  Variables 

It  is  shown  that  all  existential  variables  can  be  eliminated  from  the  constraint  generated  after  the 
example  in  the  last  subsection  is  elaborated.  Our  observation  indicates  that  this  is  the  case  for 
almost  of  all  the  examples  in  our  experiment.  This  suggests  that  we  eliminate  as  many  existential 
quantifiers  as  possible  in  a  constraint  before  passing  it  to  a  constraint  solver. 

The  rule  for  eliminating  existential  quantifiers  in  constraints  are  presented  in  Figure  4.13.  A 
judgement  of  form  (j)  \~  i  :  7  =7-  $  means  that  cf)  h  i  :  7  is  derivable  if  0  |=  $  is.  This  is  reflected  in 
the  following  proposition. 

Theorem  4.2.6  If  both  (f>  h  i  :  7  =>•  and  <j)  \=  $  are  derivable,  then  <f>  F  i  :  7  is  also  derivable. 

Proof  This  simply  follows  from  a  structural  induction  on  the  derivation  V  oi  <f\~  i  :  'y  +>  <&.  We 
present  one  case. 

4>  h  i  :  7  =>•  $1  (j),  a  :  7  h  P  :  o  =>•  $2 

V  = - - 

4>  h  i  :  {a  :  7  |  P}  =>•  P[a  e- ►  i]  A  $1  A  V(a  :  7). $2  Since  f>  |=  P[a  w  j]  A  A  V(a  :  7). $2 

is  derivable,  4>  |=  P[a  1— ►  i],  (f  |=  $1  and  cj>,a  :  7  h  $2  are  also  derivable.  By  induction 
hypothesis,  (j)  h  i  :  7  and  (j),  a  :  7  b  P  :  o  is  derivable.  This  leads  to  the  following. 

0bi:7  4>,a  : +  \~  P  :  o  <j>\=P[a^i\ 

- ^  .;{tt;7[p} -  (index-subset) 

All  other  cases  can  be  handled  similarly.  ■ 

We  use  solve(A  :  7;  $)  j  (?';  $;)  to  mean  that  solving  $  for  A  yields  an  index  i  and  a  constraint 
+' .  Also  solves(,0;  <h)  J,  ( 6 ;  T7)  means  that  solving  $  for  the  existential  variables  declared  in  if 
generates  a  substitution  9  with  domain  if  and  a  constraint  +' .  Finally,  elimExt(<I>)  f  T7  means 
that  eliminating  all  the  existential  variables  in  yields  a  constraint  ‘E. 
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Proposition  4.2.7  We  have  the  following. 

1.  Suppose  4>\(j>\  l-  solve(A  :  7;  <h)  j  (*;  <L/)  is  derivable.  If  (p,  (f>\  \=  <&'[A  1— ►  i]  is  derivable  then 
so  is  (j>,  (fi  |=  $  [A  1— ►  i] . 

2.  Suppose  <f>  h  solves [if]  4>)  j  (9;  4)/) .  If  <f>  \=  $/  is  derivable  then  so  is  <f\=  $[0]. 

3.  Suppose  cf  h  elimExt(<h)  j  <&'  is  derivable.  If  <f>  |=  is  derivable  then  so  is  4>  |=  <b. 

Proof  (1)  follows  from  a  structural  induction  on  the  derivation  of  4> ;  f>i  h  solve(A  :  7;4>)  |  (*;$')> 
and  (2)  follows  from  a  structural  induction  on  the  derivation  of  (f  h  solves(i/>;  <L)  j  (0;  $7)  with  the 
help  of  (1).  (3)  then  follows  from  (2).  ■ 

We  have  thus  established  the  correctness  of  the  rules  for  eliminating  existential  variables  in  con¬ 
straints. 


4.3  Summary 

The  language  ML^((7),  which  extends  the  language  MLo  with  universal  dependent  types,  is  for¬ 
mulated  to  parameterize  over  a  given  constraint  domain  C. 

We  call  the  type  system  of  ML^((7)  a  restricted  form  of  dependent  type  system  for  the  following 
reason.  We  view  both  index  objects  and  expressions  in  ML^(C)  as  terms.  In  this  view,  the  type 
of  a  term  can  depend  on  the  value  of  terms.  For  instance,  the  type  of  reverse [n]  (7),  which  is 
intlist(n),  depends  on  n.  An  alternative  is  to  view  index  objects  as  types,  and  therefore  to 
regard  the  type  system  of  MLq  (C)  as  a  polymorphic  type  system.  However,  this  alternative  leads 
some  serious  complications.  For  instance,  it  is  unclear  what  expressions  are  of  type  i  if  i  is  an  index 
object.  Also  this  view  complicates  the  interpretation  of  subset  sorts  significantly. 

The  operational  semantics  of  MLq  ((7)  is  presented  in  the  style  of  natural  semantics,  in  which 
type  indices  are  never  evaluated.  This  highlights  our  language  design  decision  which  requires  the 
reasoning  on  type  indices  be  done  statically.  It  is  then  proven  that  ML^(C)  enjoys  the  type 
preservation  property  (Theorem  4.1.6).  We  emphasize  that  one  can  always  evaluate  type  indices 
if  one  chooses  to.  However,  there  is  simply  no  such  a  need  for  doing  this.  Clearly,  this  must  be 
changed  if  run-time  type-checking  becomes  necessary,  but  we  currently  reject  all  programs  which 
cannot  pass  (dependent)  type-checking. 

Another  important  aspect  of  MLq  (C)  is  that  there  are  no  more  untyped  expressions  which  are 
typable  in  MLq  (C)  than  in  MLo  (Theorem  4.1.9).  This  distinguishes  our  study  from  those  which 
emphasize  on  enriching  a  type  system  to  make  more  expressions  typable.  Our  objective  is  to  assign 
expressions  more  accurate  types  rather  than  make  more  expressions  typable. 

Theorem  4.2.5  constitutes  a  major  contribution  of  the  thesis.  It  yields  a  strong  justification 
for  the  methodology  which  we  have  adopted  for  developing  dependent  type  systems  in  practical 
programming.  Dependent  types  and  their  usefulness  in  programming  have  been  noticed  for  at  least 
three  decades.  However,  the  great  difficulty  in  designing  a  type-checking  algorithm  for  dependent 
type  system  has  always  been  a  major  obstacle  which  hinders  the  wide  use  of  dependent  types  in 
programming.  We  briefly  explain  the  reason  as  follows. 

In  a  fully  dependent  type  system  such  as  the  one  which  underlies  LF  (Harper,  Honsell,  and 
Plotkin  1993)  or  Coq  (Coquand  and  Huet  1986),  there  is  no  differentiation  between  the  type  index 
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(j)\-  a  :  b 
(p  b  a  :  b  =>  T 

£(/)  =7  6  cp  b  *  :  7  $ 

cp  I-  f(i)  :  b  =>  $ 

4>  b  i\  :  71  =7-  $i  (/>  h  Z2  :  71  4*2 

4>  b  {ii,  12)  :  71  *  72  =>•  A  <h2 
^  h  i  :  7  7>  $1  <p,  a  :  7  h  P  :  o  7  $2 

<p  b  i  :  {a  :  7  |  P}  =7  P[a  i->  i]  A  f  1  A  V(a  :  7). $2 

^  b  i  :  7  =7  $  A  0  label(</>) 

4>]  (j>i  1-  solve(A  :  7;  A  =  i)  J,  (i;  4>) 

^  b  i  :  7  =7  $  A  0  label(</>) 

4>-  (j)  1  b  solve(A  :  7;  i  =  A)  J,  (i;  4?) 

0;  </>i,  P  b  solve(A  :  7;  <E>)  J.  (*;  $') 

(p;  pi  b  solve(yl  :  7;  P  D  4>)  j  (*;  P  D  $') 

(p\  (pi,  a  :  71  b  solve(J4  :  7;  4>)  j  (?';  $') 
b  solve(A  :  7;Va  :  71. 3>)  |  (i;Va  :  71.4b) 

(p\  (pi  b  solve(A  :  7;  $1)  |  (i;  4^) 

<p\  (pi  b  solve(A  :  7;  $1  A  $2)  I  («;  4^  A  4>2) 

(p\  <t>i  b  solved  :  7;  <b2)  I  (i;  $2) 

</>i  b  solve(A  :  7;  $1  A  $2)  I  (*;  $1  A  4>2) 

(p  b  solves(-;  4>)  J,  ([];  4>) 

<p,  A  :  7  b  solves^;  4>)  |  (0,  4>')  <p\  ■  b  solve(yl  :  7;  4>')  J,  4>" 

<p  b  solves(^4  :  7,  ip-,  4>)  j  (9  o  [A  1— >  *],  4>/,[J4  1— ►  *]) 

(p  b  elimExt(P)  j  P 

(p  b  elimExt($i)  |  4*)  (p  b  elimExt(4>2)  I  4>2 
(p  b  elimExt(4>i  A  $2)  I  4)/i  A  4>2 
(p  b  elimExt(4>)  J,  4>r 
<p  b  elimExt(P  D  $)  |  P  D  $' 

cp,  a  :  7  b  elimExt(4>)  j  4>7 
<p  b  elimExt(V(a  :  7).$)  |  V(a  :  7).4>' 
cp,  ip  b  elimExt(4>)  J,  4>'  <p\  ■  b  solves(V>;  4>')  |  (0;  4>") 

<p  b  elimExt(3('f/j).$)  j  4>" 


Figure  4.13:  The  rules  for  eliminating  existential  variables 
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objects  and  the  expressions  in  the  system.  In  other  words,  every  expression  can  be  used  as  a 
type  index  object.  Suppose  that  we  extend  the  type  system  of  MLo  with  such  a  fully  dependent 
type  system.  In  this  setting,  the  constraint  domain  C  is  the  same  as  the  programming  language 
itself,  and  therefore,  Theorem  4.2.5  offers  little  benefit  since  constraint  satisfaction  is  as  difficult 
as  program  verification,  which  seems  to  be  intractable  in  practical  programming.  This  intuitive 
argument  suggests  that  it  may  not  be  such  an  attractive  idea  to  use  fully  dependent  types  in  a 
programming  language. 

On  the  other  hand,  if  we  choose  C  to  be  some  relatively  simple  constraint  domain  for  which 
there  are  practical  approaches  to  constraint  satisfaction,  then  we  are  guaranteed  by  Theorem  4.2.5 
that  elaboration  in  MLq  (C)  can  be  made  practical.  For  instance,  the  integer  constraint  domain 
presented  in  Chapter  3  falls  into  this  category. 

Although  it  is  the  burden  of  the  programmer  to  provide  sufficient  type  annotations  in  code, 
our  experience  suggests  that  this  requirement  is  not  overwhelming  (the  part  of  type  annotations 
usually  consist  of  less  than  20%  of  the  entire  code).  Also  type  annotations  can  be  fully  trusted  as 
program  documentation  since  they  are  always  verified  mechanically,  avoiding  the  “code-changes- 
but-comments-stay-the-same”  common  symptom  in  programming.  Given  the  effectiveness  of  de¬ 
pendent  types  in  program  error  detection  and  compiler  optimization  (Chapter  9)  and  the  moderate 
number  of  type  annotations  needed  for  type-checking  a  program,  we  feel  that  the  practicality  of 
our  approach  has  gained  some  solid  justification. 


Chapter  5 


Existential  Dependent  Types 


In  this  chapter,  we  further  enrich  the  type  system  of  ML^(C)  with  existential  dependent  types, 
yielding  the  language  MLq ’S(C).  We  illustrate  through  examples  the  need  for  existential  dependent 
types,  and  then  formulate  the  corresponding  typing  rules  and  elaboration  algorithm.  This  is  similar 
to  the  development  presented  in  the  last  chapter,  although  it  is  significantly  more  involved. 

5.1  Existential  Dependent  Types 

The  need  for  existential  dependent  types  is  immediate.  The  following  example  clearly  illustrates 
one  aspect  of  this  point. 

fun  filter  pred  nil  =  nil 

I  filter  pred  (x: :xs)  =  if  pred(x)  then  x: :filter(xs)  else  filter(xs) 

The  function  filter  eliminates  all  elements  in  a  list  which  do  not  satisfy  a  given  predicate.  Given 
a  predicate  p  and  a  list  l,  we  cannot  calculate  the  length  of  filter(p)(l)  in  general  if  we  only 
know  the  types  of  p  and  l.  Therefore,  it  is  impossible  to  assign  filter  a  dependent  type  of  form 
Iln  :  nat. intli st (n)  — ►  intlist(i)  for  any  index  i.  Intuitively,  we  should  be  able  to  assign  filter 
the  type 

Ilm  :  nat. intlist(m)  — >  Tn  :  nat. intlist(n), 

where  Tn  :  nat. intlist(n)  roughly  means  an  integer  list  with  some  unknown  length. 

Another  main  reason  for  introducing  existential  dependent  types  is  to  cope  with  existing 
(library)  code.  For  instance,  let  lib  be  a  function  in  a  library  with  a  (non-dependent)  type 
intlist  — >  intlist.  In  general,  we  cannot  refine  the  type  of  lib  without  the  access  to  the 
source  code  of  lib.  Again  intuitively,  we  should  be  able  to  assign  the  function  lib  the  following  type 

(T,n  :  nat. intlist (n))  — >  (Tn  :  nat. intlist (n)) 

in  order  to  check  the  code  in  which  lib  is  called  (if  intlist  has  been  refined).  This  provides  a 
smooth  interaction  between  dependent  and  non-dependent  types. 

Also  existential  dependent  types  can  facilitate  array  bound  check  elimination.  For  example, 
in  some  implementation  of  Knuth-Morris-Pratt  string  search  algorithm,  one  computes  an  integer 
array  A  whose  elements  are  used  later  to  index  another  array  B.  If  we  could  assign  array  A  the 
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type  (X n  :  nat.int(n ))  array,  i.e.,  an  array  of  natural  numbers,  then  we  would  only  have  to  check 
whether  an  element  i  in  array  A  is  less  than  the  size  of  array  B  when  we  use  it  to  index  array  B. 
It  is  unnecessary  to  check  whether  i  is  nonnegative  since  the  type  of  i,  Xn  :  nat.int(n ),  already 
implies  this.  We  refer  the  reader  to  the  code  in  Section  A.l  for  more  details. 

Our  experience  indicates  that  existential  dependent  types  are  indispensable  in  practice.  For 
instance,  almost  all  the  examples  in  Appendix  A  use  some  existential  dependent  types. 

We  now  enrich  the  language  ML^(C)  with  existential  dependent  types,  and  call  the  enriched 
language  MLq ’S(C).  In  addition  to  the  syntax  of  ML^((7),  we  need  the  following. 


types  r 

expressions  e 
value  forms  u 
values  v 


(Xa  :  7 .t) 

<*  I  e>  I  let  ( a  I  x)  =  e\  in  e2  end 
(i  |  u) 

(i  I  v) 


The  formation  of  an  existential  dependent  type  is  given  as  follows. 


4>,  a  :  7  h  r  :  * 

<j)  h  (Xa  :  7 .r)  :  * 


(type-sig) 


Also  the  following  rule  is  needed  for  extending  the  type  congruence  relation  to  including  existential 
dependent  types. 

4>,  a  :  7  |=  r  =  t' 

(f>  |=  Xa  :  7 .r  =  Xa  :  7 .t' 

The  typing  rules  for  existential  dependent  types  are  given  below.  Note  that  (ty-sig-elim)  can  be 
applied  only  if  a  has  no  free  occurrence  in  T  and  r2. 


(j>;  T  b  e  :  r[a  1 — >•  *]  (j)  F  *  :  7 

4>;  T  h  (i  |  e)  :  (Xa  :  7 .r) 

T  h  ei  :  (Xa  :  7.T1)  (f>,  a  :  7;  T,  x  :  T\  h  e2  :  r2 


i;  T  h  let  (a  |  x)  =  ei  in  e2  end  :  r2 


(ty-sig-intro) 

(ty-sig-elim) 


In  addition  to  the  evaluation  rules  in  Figure  4.6,  we  need  the  following  rules  to  formulate  the 


natural  semantics  of  ML|jI’"J(C'). 


>d  v 


ei 


{i  |  e)  ^ d  {i  |  v) 
>d{i\vi)  e2 [a 


(ev-sig-intro) 

vi] 


let  (a  |  x)  =  e\  in  e2  end  c— u2 


(ev-sig-elim) 


n  e 

Now  let  us  prove  some  expected  properties  of  ML0  ’  (C).  This  part  of  the  development  of 
MLo’S(<7)  is  parallel  to  that  of  MLq  (C). 

ns  ns 

Theorem  5.1.1  (Type  preservation  in  ML0  ’  (C))  Given  e,v  in  ML0  ’  (C)  such  that  e  v  is 
derivable.  If  (j)]T  \~  e  :  t  is  derivable,  then  (f;T  h  v  :  r  is  derivable. 

Proof  The  theorem  follows  from  a  structural  induction  on  the  derivation  V  of  e  v  and  the 
derivation  of  <f>;  T  b  e  :  r,  lexicographically  ordered.  This  is  similar  to  the  proof  of  Theorem  4.1.6 
We  present  several  cases. 
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ei  d  vi 

V  = - 

(i  |  e\)  (i  |  v\)  The  last  applied  rule  in  the  derivation  0;  T  b  e  :  r  is  of  the  following 
form. 


T  h  ei  :  ri  [a  i]  (j)  b  i  :  7 


(ty-sig-intro) 


</>;  T  b  (i  |  ei)  :  Ea  :  7.T1 
By  induction  hypothesis,  </>;T  b  ty  :  ri[a  1— >  i]  is  derivable,  and  this  leads  to  the  following. 


0;  T  b  v\  :  T\  [a  i]  cf)  b  i  :  7 
(/>;  T  b  (i  |  ui)  :  Ea  :  7.T1 


(ty-sig-intro) 


V  = 


ei  ^ d  (i  |  n)  e2[a  ^  i][r  w  vi]  ^ d  v2 


let  (a  |  x)  =  e\  in  e2  end 
of  form: 

</>;  T  b  ei  :  Ea  :  7-Ti 


d  v2  The  last  rule  in  the  derivation  of  T  b  e  :  r  is 

(f>,  a  :  7;  T,  x  :  n  b  e2  :  r2 


i;  T  b  let  (a  |  x)  =  ei  in  e2  end  :  r 


(ty-sig-elim) 


By  induction  hypothesis,  0;  T  b  (i  |  ty)  :  Ea  :  7. 77  is  derivable.  This  implies  that  (/>  b  i  :  7 
and  0;T  b  ty  :  ri[a  w  i]  are  derivable.  Since  (j>,  a  :  7;  T,  x  :  n  b  e2  :  r2  is  derivable  and 
a  has  no  free  occurrences  in  V  and  r2,  a  proof  of  r/>; T  b  e2[a  1— >•  i][x  1— >  ty]  :  t2  can  also  be 
constructed.  By  induction  hypothesis,  ^;fbv2:r2  is  derivable. 


The  other  cases  can  be  treated  similarly. 


We  extend  the  definition  of  the  index  erasure  function  ||  •  ||  as  follows. 

IK*  I  e)ll  =  llell 

1 1  let  (a  |  x)  =  ei  in  e2  end||  =  let  x  =  ||ei||  in  |je2||  end 

Then  Theorem  4.1.9,  Theorem  4.1.10  and  Theorem  4.1.12  all  have  their  corresponding  versions  in 

n  s 

ML0’  (C),  which  we  mention  briefly  as  follows. 

n  s 

Theorem  5.1.2  //<^>;T  b  e  :  t  is  derivable  in  ML0  ’  (C),  then  ||r||  b  ||e||  :  ||r||  is  derivable  in 
ML0. 


Proof  This  simply  follows  from  a  structural  induction  on  the  derivation  V  of  </>;  T  b  e  :  r.  We 
present  some  cases. 

4>\  T  b  e\  :  ri  [a  1— ►  i]  b  i  :  7 

4>]T  b  (i  |  ei)  :  Ea  :  7.T1  By  induction  hypothesis,  ||r||  b  ||ei||  :  [|n[a  1— >  i]||  is  deriv¬ 
able.  Since  ||ri[a  1— ►  *]||  =  ||n||  =  |  j  Ea  :  7.T1II  and  ||(*  |  ei)||  =  ||ei||,  we  are  done. 

4>]  T  b  ei  :  (S a  :  7. 77)  </>,  a  :  7;  T,  x  :  77  b  e2  :  r2 

D  = - 

</>;T  b  let  (a  |  x)  =  e\  in  e2  end  :  r2  By  induction  hypothesis,  ||r||  b  ||ei|j  : 

|| Ea  :  7. n||  and  ||T,x  :  n||  b  ||e2||  :  ||r2||  are  derivable.  Since  ||Ea  :  7.T1II  =  ||n||  and 
|| r, x  :  n||  =  || r || , x  l  ||n||>  this  leads  to  the  following. 
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Note  that  | j let  (a  \  x)  =  e\  in  e2  end||  is  let  x  =  1 1 e 1 1 1  in  1 1 eo 1 1  end,  and  we  are  done. 

All  other  cases  can  be  treated  similarly.  ■ 

Like  MLj^C*),  the  evaluation  in  MLqI’S(C)  can  be  simulated  by  the  evaluation  in  MLo-  This  is 
stated  in  the  theorem  below. 

n  s 

Theorem  5.1.3  If  e  ^ d  v  derivable  in  ML0  ’  ( C ),  then  ||e||  IMI  derivable  in  MLq. 


Proof  This  simply  follows  from  a  structural  induction  on  the  derivation  V  of  e  ^d  v.  We  present 
a  few  cases  as  follows. 

ei  <-+d  Vi 

V  = - 

(i  |  e\)  c-> d  {i  |  ui)  Then  ||ei||  lki||  is  derivable  by  induction  hypothesis.  Since 

IK*  I  ei)ll  =  INI  and  IK*  I  *>i)ll  =  IM> 

we  are  done. 

ei  d  (i  |  vi)  e2[a  i->  i\[x  Vl\  <-^d  v 

V  = - - - - - 

let  (a  |  x }  =  e\  in  e2  end  >d  v  By  induction  hypothesis,  both 


llei||  IK*  I  vi)ll  and  lle2[a  ^  i\[x  ui]||  ||w|| 

are  derivable.  Note  ||(i  |  ui)||  =  ||ui||  and  ||e2[a  i— ►  i][x  i— >  ui]||  =  ||e2 1| ||ui||].  This  leads 
to  the  following. 


ei 


>o  \\vi\ 


e2  \x 


(ev-let) 


let  x  =  || ei  ||  in  || e2 1|  end  v 
Since  || let  (a  \  x)  =  e\  in  e2  end||  is  let  x  =  ||ei||  in  ||e2 1|  end,  we  are  done. 

All  other  cases  can  be  handled  similarly.  ■ 

Like  Lemma  4.1.11,  the  following  lemma  is  needed  in  the  proof  of  Theorem  5.1.5. 

n  s 

Lemma  5.1.4  Given  a  value  v\  in  ML0  ’  (C)  such  that  <j>\  ■  h  v\  :  Xa  :  y.T  is  derivable,  v\  must 
be  of  form  (i  \  v2)  for  some  value  v2. 


Proof  This  follows  from  a  structural  induction  on  the  derivation  T>  of  v\. 

\  ■  h  v\  :  T\  (j)  |=  Ti  =  Sa  :  7 .r 
V  = - - 

0;  •  b  v\  :  Sa  :  7 .r  Then  T\  must  be  of  form  £a  :  7 .t[.  By  induction  hy¬ 

pothesis,  v\  has  the  claimed  form. 

\  ■  b  v  :  r[a  1— ■»  i]  (/>  h  i  :  7 

■  h  (i  |  v)  :  (Sa  :  7 .r)  Then  v\  is  (i  \  v),  and  we  are  done. 


Note  that  the  last  applied  rule  in  T>  cannot  be  (ty-var).  Since  v\  is  a  value,  no  other  rules  can  be 
the  last  applied  rule  in  V.  This  concludes  the  proof.  ■ 
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Theorem  5.1.5  Given  </>;  •  h  e  :  r  derivable  in  ML^(C).  If  e°  =  ||e||  >o  w0  derivable  for 
some  value  v°  in  MLo,  then  there  exists  a  value  v  in  ML^  ,S(C)  such  that  e  ► d  v  is  derivable  and 
III)  1 1  =  v® . 


Proof  The  theorem  follows  from  a  structural  induction  on  the  derivation  of  e°  ^->o  v°  and  the 
derivation  T>  of  </>;  ■  h  e  :  r,  lexicographically  ordered.  We  present  a  few  cases. 


■  \~  e\  ■.  T\[a  ^  i]  cf)  h  i  :  7 

(/>;  ■  h  (i  |  ei)  :  (Ea  :  7.77)  Then  ||(i  |  ei)||  =  ||ei||  ^0  is  derivable  in  MLo-  By 

induction  hypothesis,  ei  ^->d  v\  is  derivable  in  MLj^’^C1)  such  that  ||ui||  =  u°.  This  yields 
the  following. 


ei  ^ d  vi 


(i  |  ei)  ^ d  (i  I  vi) 
Note  that  ||(i  |  77)  ||  =  ||ui||  =  v°,  and  we  are  done. 


(ev-sig-intro) 


</>;-h  e-i  :  (Sa  :  7.T1) 

<f;  ■  h  let  (a  |  x) 
following  form 


cj),  a  :  7;  x  :  77  h  e2  :  r 

ei  in  e2  end  :  r  Then  the  derivation  of  ||e||  c— >0  is  of  the 


IMI^o^i  1 1  e2 1 1  [a?  u?]  v° 
let  x  =  || ei  ||  in  || e2 1|  end  ^0  v° 


(ev-let) 


By  induction  hypothesis,  e\  ^>d  v\  is  derivable  for  some  v\  such  that  ||ui||  =  v®.  By  The¬ 
orem  5.1.1,  <f>\-  \~  v  1  :  (Sa  :  7.77)  is  derivable.  Therefore,  Lemma  5.1.4  implies  that  v\  is 
of  form  (i  \  v2)  for  some  v2.  It  then  follows  that  both  ^  ■  h  r2  :  7(0  ^  i]  and  (f  b  i  :  7 
are  derivable.  This  leads  to  a  derivation  of  (j>\  ■  h  e2[a  1— ►  *][#  i-»  v2]  :  r  since  r  contains  no 
free  occurrences  of  a.  Notice  ||e2[a  1— >  i][x  1— >  u2]||  =  ||e2||[x  1— >  u®].  By  induction  hypothesis, 
e2[a  1— ►  i]  [x  1— >  v2]  ^d  v  is  derivable  for  some  v  such  that  ||r>||  =  v°.  Hence,  we  have  the 
following,  and  we  are  done. 


ei  ^ d  (i  |  v2)  e2[a  ni][iH  v2\  ^ d  v 


let  (a  |  x)  =  e\  in  e2  end 


v 


(ev-sig-elim) 


All  other  cases  can  be  handled  similarly.  ■ 

As  a  consequence,  it  is  straightforward  to  conclude  that  MLq ’S(C),  like  MLq  (C),  is  also  a  conser¬ 
vative  extension  of  MLq. 


5.2  Elaboration 

n  e 

In  order  to  make  ML0  ’  (C)  suitable  as  a  practical  programming  language,  we  have  to  be  able  to 

n  s 

design  a  satisfactory  elaboration  algorithm  from  DML(C)  to  ML0  ’  ( C ),  where  DML(C)  is  basically 
the  external  language  DMLo(C)  present  in  Section  4.2  except  that  existential  dependent  types  are 
allowed  now.  This  turns  out  to  be  a  challenging  task. 

We  present  a  typical  conflict  which  we  are  facing  in  order  to  do  elaboration  in  this  setting. 
Let  us  assign  the  type  nn  :  naf.intlist(n)  — ►  intlist(n)  to  the  function  rev  which  reverses 
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an  integer  list.  Suppose  that  rev (l )  occurs  in  the  code,  where  l  is  an  integer  list.  Intuitively,  we 
synthesize  rev  to  rev[i]  for  some  index  i  subject  to  the  satisfiability  of  the  index  constraints,  and 
then  we  check  l  against  type  intlist(i).  Suppose  we  then  need  to  synthesize  l,  obtaining  some 
l*  with  type  Xn  :  nat. intlist(ro).  We  now  get  stuck  because  l*  cannot  be  (successfully)  checked 
against  intlist(i)  for  whatever  i  is,  and  a  type  error  should  then  be  reported.  Nonetheless,  it 
seems  quite  natural  in  this  case  to  elaborate  rev(l )  into 

let  (a  |  x)  =  T  in  (a  \  rev[a\(x ))  end, 

which  is  of  type  Xa  :  nat. intlist(a).  This  justifies  the  intuition  that  reversing  a  list  with  unknown 
length  yields  a  list  with  unknown  length  1 .  The  crucial  step  is  to  unpack  l  before  we  synthesize  rev 
to  rev[i].  Also  notice  that  this  elaboration  of  rev(l )  does  not  alter  the  operational  semantics  of 
rev(l),  although  it  changes  the  structure  of  the  expression  significantly. 

This  example  suggest  that  we  transform  revlfl )  into  let  x  =  l  in  rev{x)  end  before  elaboration. 
In  general,  we  can  define  a  variant  of  A-normal  transform  (Moggi  1989;  Sabry  and  Felleisen  1993) 
as  follows,  which  transforms  expressions  e  in  DML(C')  into  e. 


let  x 


x  =  x 


lam  x.e 

=  lam  x.e 

lam  x  :  r.e 

=  lam  x  :  r.e 

fix  f.e 

=  fix  f.e 

fix  /  :  r.e 

=  fix  /  :  r.e 

0 

=  0 

c 

=  c 

c(e) 

=  let  x  =  e  in  c(x)  end 

case  e  of  ms 

=  let  x  =  e  in  case  x  of  ms 

end 

p  =3-  e 

=  p  =!>  e 

(ei,e2) 

=  let  x\  =  e\  in  let  X2  =  e2 

in  lx\ixf)  end  end 

ei(e2) 

=  let  x\  =  e\  in  let  X2  =  e2 

in  X\(x2)  end  end 

:  e\  in  e2  end 

=  let  x  =  e\  in  e2  end 

e  :  r 

=  e  :  r 

The  following  proposition  shows  that  e  preserves  the  operational  semantics  of  the  transformed 
expression  e. 

Proposition  5.2.1  We  have  \e\  =  |e|  for  all  expressions  e  in  DML(C). 

Proof  With  Corollary  2.3.13,  this  follows  from  a  structural  induction  on  e.  ■ 

The  strategy  to  transform  e  into  e  before  elaborating  e  means  that  we  must  synthesize  the  types 
of  e\  and  e2  in  order  to  synthesize  the  type  of  an  application  ei(e2)  since  it  is  transformed  into 
let  x\  =  e\  in  let  X2  =  e2  in  x\(x2)  end  end.  Clearly,  this  strategy  rules  out  the  following  style 
of  elaboration,  which  would  otherwise  exist.  For  instance,  let  us  assume  that  the  type  of  e\ 

Tt  is  tempting  to  require  that  reversing  a  list  with  unknown  length  yield  a  list  with  the  same  unknown  length. 
This,  however,  is  not  helpful  to  justify  that  (l,  rev(l))  is  a  pair  of  lists  with  the  same  length  if  we  enrich  our  language 
further  to  include  effects.  If  l  has  no  effects,  this  can  be  achieved  using  let  x  =  l  in  {x,  rev{x )}  end. 
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is  Ila  :  7 .(5(a)  —>  5(a))  — >  5(a)  and  is  lam  x.x\  then  synthesizing  the  type  of  e2  is  clearly 
impossible  but  the  type  of  ei(e2)  can  nonetheless  be  synthesized  as  follows. 

</>;T  h  e\  |  Ila  :  7. (5(a)  — >  5(a))  — >  5(a)  e\ 

</>;T  b  e\  |  (5(i)  — >  5(i))  — >  5(i)  e\[i]  c/>;T  h  e2  |  5(i)  — >  5(i)  =7>  (lam  x  :  5(i).x) 

4>;  T  b  ei(e2)  T  5(i)  e^[i](lam  x  :  5(i).x) 

It  has  been  observed  that  this  style  of  programming  does  occur  occasionally  in  practice.  Therefore, 
we  are  prompted  with  a  question  about  whether  the  above  transform  should  always  be  performed 
before  elaboration  begins.  There  is  no  clear  answer  to  this  question  at  this  moment.  On  one  hand, 
we  may  require  that  the  programmer  perform  the  transform  manually  but  this  could  be  too  much 
of  a  burden.  On  the  other  hand,  if  the  transform  is  always  performed  automatically,  then  we  may 
lose  the  ability  to  elaborate  some  programs  which  would  otherwise  be  possible.  More  importantly, 
this  could  make  it  much  harder  to  report  informative  error  messages  during  type-checking.  Given 
that  this  issue  has  yet  to  be  settled  in  practice,  it  is  desirable  for  us  to  separate  from  elaboration 
the  issue  of  transforming  programs.  We  will  address  in  Chapter  8  the  practical  issues  involving 
program  transform  before  elaboration. 

In  the  following  presentation,  we  will  use  a  for  a  (possibly  empty)  sequence  of  index  variables 
and  7  for  a  (possibly  empty)  sequence  of  sorts.  Also  we  use  a  :  7  for  a  sequence  of  declarations 
a\  :  71, . . . ,  an  :  7n,  where  a  =  a±, . . . ,  an  and  7  =  71, ... ,  7„,  and  X(a  :  7 ).r  for  the  following. 

£(ai  :  71)  . . .  £(an  :  7 n)-r. 

We  use  (a  |  e)  and  let  (a  |  x)  =  e\  in  e2  end  for  the  abbreviations  defined  as  follows.  If  a  is 
empty,  we  have 

(a  |  e)  =  e  let  (a  \  x)  =  e\  in  e 2  end  =  let  x  =  e\  in  e2  end 

and  if  a  is  a,  al,  we  have 

(a  |  e)  =  (a  |  (al  |  e)) 

let  (a  |  x)  =  e\  in  e2  end  =  let  (a  |  37}  =  e\  in  let  (a)  |  x)  =  x\  in  e2  end  end 
The  following  proposition  presents  some  properties  related  to  these  abbreviations. 

Proposition  5.2.2  We  have  the  following. 

— ♦  •  •  ns 

1.  |  let  (a  |  x)  =  e\  in  e2  end  =  let  x  =  | ei |  in  | e2 1  end  for  expressions  ei,e2  in  ML0  ’  (C). 

2.  Suppose  that  both  f>;T  \~  e±  :  E(a  :  7).ri  and  <p,  a  :  7;  T,  x  :  77  h  e2  :  T2  are  derivable.  If  none 
of  the  variables  in  a  have  free  occurrences  in  72  then  V  b  let  (a  |  x)  =  e\  in  e2  end  :  72  is 
derivable. 

Proof  (1)  simply  follows  from  Corollary  2.3.13,  and  (2)  follows  from  an  induction  on  the  number 
of  index  variables  declared  in  a.  ■ 

In  addition,  the  above  rev(l)  example  suggests  that  we  turn  both  the  rules  (elab-let-up) 
and  (elab-let-down)  into  the  following  forms,  respectively.  In  other  words,  we  always  unpack  a 
let-bound  expression  if  its  synthesized  type  begins  with  existential  quantifiers. 

_ &  T  I-  ei  t  S(q  :  7)777  =>  e\  (f,  a  :  7;  T,  x  :  77  h  e2  T  ^2  e*2 _ 

4>;  T  b  let  x  =  ei  in  e2  end  |  S(a  :  7).T2  =$■  let  (a  |  x)  =  e\  in  (a  |  e^)  end 
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<t>\  r  I-  ei  t  E(a  :  j).ti  =>  e\  (j>,  a  :  7;  T,  x  :  n  b  e2  |  r2  =7- 

(/)]  r  b  let  x  =  ei  in  e2  end  I  t2  =7  let  (a  |  x)  —  e1  in  e2  end 

The  rule  (elab-case)  must  be  dealt  with  similarly. 

There  is  yet  another  issue.  Suppose  that  we  need  to  check  an  expression  e  against  a  type  r.  If 
e  is  a  variable  or  an  application,  we  must  synthesize  the  type  of  e,  obtaining  some  type  r' .  At  this 
stage,  we  need  to  check  whether  an  expression  of  type  t'  can  be  coerced  into  one  of  type  r.  The 
strategy  used  in  the  elaboration  for  ML^(C)  is  simply  to  check  whether  t'  =  r  holds.  However, 
this  strategy  is  highly  unsatisfactory  for  MLq ’S(C)  in  practice.  We  are  thus  motivated  to  design  a 
more  effective  approach  to  coercion. 

5.2.1  Coercion 

n  e 

Given  types  ti  and  72  in  ML0  ’  (C)  such  that  ||ti||  =  1 1 T2 1 1 ,  a  coercion  from  t\  to  T2  is  an  evaluation 

context  E  such  that  for  every  expression  e  of  type  ti,  E[e\  is  of  type  72  and  |e|  =  |E[e]|. 

In  Figure  5.1  we  present  the  rules  for  coercion  in  MLq’S(C).  A  judgement  of  form  <f  b 
coerce(r,  r')  =7  E  means  that  every  expression  e  of  type  r  can  be  coerced  into  expression  E[e]  of 
type  t'. 

Example  5.2.3  We  show  that  the  type  r  =  na  :  7 .6(a)  — ►  6(a)  can  be  coerced  into  the  type 
t'  =  Ha  :  7.6(a) -^Eb:  7.6(b). 

a  :  7  |=  a  =  a 

a  :  7  |=  a  =  a  0:7V-  coerce(<5(a),  6(a))  =7  [] 

a  :  7  \~  coerce(<5(a),  5(a))  =7>  []  a  :  7  coerce(5(a),  Eb  :  7.6(b))  =7  (a  \  []) 
a:  7  b  coerce(d(a)  — >  6(a), 6(a)  —>  Eb  :  7.6(b))  =7  let  x\  =  []  in  lam  X2  :  5(a). (a  \  x\(x2))  end 
a  :  7  h  coerce(r,  5(a)  — >  Eb  :  7.6(b))  =7  let  x\  =  [][a]  in  lam  X2  :  5(a). (a  \  x±(x2))  end 
•  b  coerc  e(r,  r')  =7  A  a  :  7. let  x\  =  [][a]  in  lam  x'2  :  5(a). (a  |  xi(x2))  end 

We  are  ready  to  prove  the  correctness  of  these  coercion  rules,  which  is  stated  as  Theorem  5.2.4. 

Theorem  5.2.4  If  (f>;  T  h  e  :  r  and  (j)  h  coerce(r,  t')  =7  E  are  derivable,  then  4>]  T  b  E\e]  :  r  is 
also  derivable  and  |e|  =  |E[e]|. 

Proof  This  follows  from  a  structural  induction  on  the  derivation  V  of  4>  b  coerc e(r,  t')  =7  E. 
We  present  several  cases. 

cj)  b  coerce(ri,  t[)  =7  E 1  <j>\-  coerce(r2,  t!2)  =7  E2 

cj)  b  coerce(ri  *  T2,  *  t'2)  =7  case  []  of  (x\,  xf)  =7  (E\[xi\,  E2[x2\)  By  induction  hypoth¬ 
esis,  <f>;  T,  x\  :  r\,X2  :  t2\~  E\[x\]  :  t[  and  4>;  T,  x\  :  t\,X2  :  t2\~  E2 \xf\  :  t2  are  derivable.  This 
leads  to  the  following  derivation, 

(xi,x2)  |  ri  *t2>  (•;  xi  :  n,x2  :  r2)  T>o  ti_  ,  .  . 

- - - - - — - — - - — — - - - j  (ty-matcnj 

<p;  T  b  e  :  Ti  *  72  </>;  T  b  (x\,  x2)  =7  (Ei  xi  ,  E2  x2  )  :  n  *  72  =7  tx  *  r2  . 

_  /  j 

4>-,T  b  (case  e  of  (xi,x2)  =4-  (Ei[xi],  E2[x2]))  :  t[*t2 
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_ <t>  1=  i  =  3 _ 

(j)  b  coerc e(S(i),S(j))  =7  [] 

b  (/>[ictx] 

4>  b  coerce(l,  1)  =7  [] 
cj)  b  coerce(ri,  r{)  =7  Ei  cj)  b  coerce(r2,  t'2 


(coerce-datatype) 


(coerce-unit) 

E2 


(j)  b  coerce(ri  *T2,t'1*t!2)  =>  case  []  of  {x\,x2)  (Ei[xi],  E2[x2]) 
4>  b  coerce(r{ ,  ri)  =7-  E\  (f>\-  coerce(r2,  t!2)  =7  E2 


b  coerce(ri 


t-2,  t[  — ►  t'2)  =7  let  xi  =  []  in  lam  x2  :  t[.E2[xi(Ei[x2])\  end 
4>  b  coerce(ri  [a  >— >  i] ,  r)  =7  E  </>b  i  :  7 


(coerce-prod) 

(coerce-fun) 


b  coerce(IIa  :  7.T1,  r)  =►  E[[][i]] 
4>,  a  :  7  b  coerce(ri,  r)  =7  E 


(coerce-pi-1) 


b  coerce(ri,IIa  :  y.r)  =7  Aa  :  7.E 
</>,  a  :  7  b  coerce(ri,  r)  =7  E 


cj)  b  coerce(£(a  :  7 ).ti,t)  =7  let  (a  |  x)  =  []  in  E[x]  end 
cj)  b  coerce(ri,  r[a  h  j])  7  E  (j)  b  i  :  7 


(coerce-pi-r) 

(coerce-sig-1) 


4>  b  coerce(n,  S(a  :  7).r)  =7  (i  \  E) 


(coerce-sig-r) 


Figure  5.1:  The  derivation  rules  for  coercion 
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where  T> o  is  the  following. 


(/>;  T,  xi  :  ri,  x2  :  r2  b  Ei[xi]  :  </>;  T,  27  :  n,  x2  :  r2  b  £2  [2:2]  •  r2 

</>;  T,  xi  :  T!,X2  :  t2  b  (£i[£i],  :  t[  *  t2 


(ty-prod) 


In  addition,  we  have  x\  =  |^i[xi]|  and  X2  =  |  -£^2  [^2]  |  -  Therefore, 

|case  e  of  (. X\,X2 )  =4>  (E\[x\\,  ^2 [^2] ) |  —  (case  e  of  (£1,2:2)  =$■  (£i,£2)| 

Since  e  is  of  type  r\  *  72,  it  can  then  be  shown  that  |e|  =  |case  e  of  (2:1, 2:2)  =$■  (2:1, 2:2) |. 


4>  b  coerce(r( ,  ri)  =>  E\  <p\~  coerce(r2,  t'2)  =>  E2 
4>  b  coerce(ri  — ►  t2,t[  — >  r'2)  =>  let  £1  =  []  in  lam  x2  :  end 

hypothesis,  <)>;r,£2  :  t[  b  [^2]  :  77  is  derivable.  This  leads  to  the  following. 

(j);  r,  27  :  n  -»  72, 2:2  :  b  x\  :  n  -»  r2  <ft;  T,  £7  :  77  ->  r2,  £2  •  b  Ex [x2]  :  77 
<j>\  r,  £1  :  17  ->  r2,  £2  :  t[  b  x^E^x^)  :  t2 


By  induction 


(ty-app) 


Then  by  induction  hypothesis  again,  0;T, 2:1  :  t\  t2ix2  :  t[  \~  E2[xi(Ei[x2])\  :  r2  is 
derivable,  and  this  yields  the  following. 


(j)\T,xi  :  Ti  ->  t2,x2  :  r(  b  E2[xi(Ei[x2\)]  :  T2 
0;  T  b  e  :  n  — >  T2  (j>‘,  T,  x\  :  n  — >  t2  b  lam  £2  :  r{  .£2  [27  (Ed  [£2])]  :  r(  — ►  £2 
0;T  b  let  xi  =  e  in  lam  x2  :  .£^2 [a^i (-E^i  [£2] )]  end  :  t[  —■ >  t2 


(ty-lam) 

(ty-let) 


Also  we  have  the  following  since  </>;  T  b  e  :  ri  £2  is  derivable. 

|let  £1  =  e  in  lam  x2  :  t[.E2[xi(Ei[x2])\  end| 

=  let  £1  =  |e|  in  lam  £2-) ^2 [2:1  (-®i [2:2])] |  end 
=  let  £1  =  |e|  in  lam  £2-£i(.£2)  end 
=  let  £1  =  |e|  in  £1  end  (by  Proposition  2.3.14  (1)) 

-  Iel 

This  wraps  up  the  case. 


V  =- 


b  coerce(ri[a 


1  ,r 


E 


b  i  :  7 


V  = 


cj)  b  coerce(IIa  :  7.T1, r)  =$■  E[[]i]  Since  (p;T  be:  Ila  :  7.T1 ,  we  have  the  following. 

0;  T  b  e  :  Ila  :  7.T1  (f>  b  i  :  7  . 

-  r, - r - -  (ty-iapp) 

<7;  1  b  e[zj  :  Ti[a  1— >  zj 

By  induction  hypothesis,  i);Tb  £[e[z]]  :  r  is  derivable  and  |e[z]|  =  |£[e[z]]|.  Note  |e|  =  |e[z]|, 
and  we  are  done. 

(f>,  a  :  7  b  coerce(ri,  r)  =>•  E 


(p  b  coerce(ri,  Ila  :  7.7")  =$■  Xa.'y.E  By  induction  hypothesis,  cp,a  :  y;T  b  E[e]  :  r  is 
derivable  and  |e|  =  |E7[e]|.  Since  there  are  no  free  occurrences  of  a  in  the  types  of  the 
variables  declared  in  T,  we  have  the  following. 

<p,  a  :  7;  T  b  E[e\  :  r 


4>,  a  :  7;  T  b  Xa  :  7 .£[e]  :  r 

Also  |Aa  :  7.£[e]|  =  | ^7[e] |  =  |e|.  Hence  we  are  done. 


(ty-ilam) 
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<j),a  :  7  h  coerce(ri,  r)  =>  E 

4>  b  coerce(£(a  :  7).ri,r)  =>•  let  (a  \  x)  =  []  in  E[x\  end  By  induction  hypothesis,  f>,a  : 
7;  T,  x  :  t\  b  E[x\  :  t  is  derivable.  This  leads  to  the  following. 


</>;T  be:  E(a  :  7).ri  <f,  a  :  7;  T,  x  :  77  b  _F[x]  :  r 

(f);  T  b  let  (a  |  x)  =  e  in  E[x\  end 


(ty-sig-elim) 


Notice  that 


|let  (a  |  x)  =  e  in  .E[x]  end|  =  let  x  =  |e|  in  |E'[x]|  end  =  let  x  =  |e|  in  x  end  =  |e 
Hence  we  are  done. 


cj)  b  coerce(ri,  r[a  i])  E  <7^  b  z  :  7 

(j)  b  coerce(ri,  X(a  :  7).r)  (*  |  E)  By  induction  hypothesis,  0;  T  b  S[e]  :  r[a  1— ►  i] 

is  derivable  and  |e|  =  |i£[e]|.  This  leads  to  the  following. 


(j>;  T  b  TT[e]  :  r[a  1 — ^  z]  0  b  i  :  7 
(j)]  T  b  (i  |  E[e\)  :  Sa  :  7.T 


(ty-sig-intro) 


Also  |(i  |  -F[e])|  =  \E[e]\  =  |e|,  and  we  are  done. 

All  the  rest  of  cases  can  be  treated  similarly.  ■ 

As  usual,  there  is  a  gap  between  the  elaboration  rules  for  coercion  and  their  implementation. 
We  bridge  the  gap  by  presenting  the  constraint  generation  rules  for  coercion  in  Figure  5.2.  A 
judgement  of  form  <f>  b [if)]  coerce(r,  t')  =7-  means  that  coercing  r  into  t'  under  context  <f>  yields 
a  constraint  $  in  which  all  existential  variables  are  declared  in  ij). 


Theorem  5.2.5  Assume  that  <f>  b[^>]  coerce(r,  r’)  =7-  is  derivable.  If  4>[9]  |=  <h[0]  is  derivable 
for  some  existential  substitution  6  such  that  4>  >  6  :  if  holds,  then  <f\9]  b  coerce(r[6)],  t'[9})  =7-  E  is 
derivable  for  some  evaluation  context  E. 


Proof  The  proof  proceeds  by  a  structural  induction  on  the  derivation  V  of  <f>  b[^]  coerce(r,  r')  =7- 
<h.  We  present  a  few  cases. 

4>  \~\ip\  coerce(ri,  t[)  =7-  <&i  b [tp\  coerce(r2,  t'2)  =7-  $2 

4>  b [if]  coerce(ri  *  T2,  t{  *  r 2)  =7-  $1  A  $2  Then  f>[9]  |=  (d>i Ad>2)  [0]  is  deriv¬ 

able,  and  this  implies  both  <f[9 ]  |=  <&i[0]  and  (p[9 ]  |=  ^>2  [^]  are  derivable.  By  induction  hy¬ 
pothesis,  there  are  evaluation  contexts  E\  and  E2  such  that  4>[9]  b  coerce(ri[0], t[[9})  =7-  E\ 
and  (j)[9 ]  b  coerce(r2[0], t^#])  =7-  E2  are  derivable.  This  yields  the  following. 

f>[9\  b  coerce(ri  [0] ,  t[[9})  =7-  E\  <f[9]  b  coerce(r2[0],  t'2[9})  =7-  E2 
(f)[9]  b  coerce(n[6>]  *  t2[9],t[[9]  *  t'2[9 ])  =7-  case  []  of  (xi,x2)  =7-  (Ei[xi\,  E2[x2\) 
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Figure  5.2:  The  constraint  generation  rules  for  coercion 
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4>  I ~[if,  A  :  7]  coerce(ri[a  i— >  A],  r)  =7  $1 

4>  coerce(IIa  :  7.77,7-)  =7-  3A  :  7.$!  Then  <f>[9]  j=  (3A  :  7.^1) [0]  is  derivable.  Since 
(HA  :  7.$i)[0]  is  3A  :  7[0].$i[0],  there  exists  some  i  such  that  <j>[9\  b  i  :  7)6*]  and  <j)[Q\  |=  $i[0i] 
for  9\  =  9[A  1— ►  *].  Clearly,  <f>[9 1]  =  ft[9].  By  induction  hypothesis, 

<t>[9\\  b  coerce(r[@i], t'[9]\)  =7  £j 

is  derivable  for  some  evaluation  context  E\.  Note  (ti[o  1— ►  A])[$i]  =  (ri[a  1— ►  i])[0]  and 
t[9\]  =  t[9\.  This  leads  to  the  following. 

(f)[9\  b  coerce(n[0][a  i],r[9])  =7  Ex  ft[9\  b  i  :  j[9\ 

<j>[9 }  b  coerce(na  :  7.ti[6>],  t[9})  =7  £1  [[][*]]  (c°-cons  ^P1'  ) 


4>,  aft  :  7  \~[if\  coerce(n[a  1— >  aft],  r)  =7  $1 

<f>  \-[ft\  coerce(Sa  :  7.ri,r)  =7  \/(aft  :  7).$!  Then  (j)[9\  \=  (Haft  :  7.<&i)[0]  is  derivable  for 

some  6  such  that  <j>  >  9  :  ip  holds.  Notice  that  (Ila^  :  7.<&i)[0]  is  n aft  :  7[0].<J>i[0].  Hence, 
cf)[9\,aft  :  7 [9]  |=  T 1  [9]  is  derivable.  By  induction  hypothesis,  the  following  is  derivable  for 
some  E\. 

(f>[9\,aft  :  7 [9]  b  coerce((n[a  1— ►  a^])[0],  t[9\)  =7  E\ 

Note  that  (ri[a  1— ►  a^])[0]  =  t  1  [6] [a  1— ►  aft].  This  leads  to  the  following. 


cf>[9],aft  :  7 [9\  b  coerce(ri [0] [a  1— ►  aft],r[9})  =7  E\ 

4>[9\  b  coerce(Ea  :  7[0].7y[0],  r[0])  =7  let  (a  \  x)  =  []  in  E\[x]  end 


(co-constr-sig-1) 


Hence,  we  are  done. 

All  other  cases  can  be  handled  similarly.  ■ 

We  now  have  justified  the  correctness  of  the  constraint  generation  rules  for  coercion.  However, 
there  is  still  some  indeterminacy  in  these  rules,  which  we  will  address  in  Chapter  8. 


5.2.2  Elaboration  as  Static  Semantics 

n  s 

We  list  the  elaboration  rules  for  ML0  ’  ( C )  in  Figure  5.3  and  Figure  5.4.  The  meaning  of  the 

judgements  ft  F  b  e  f  r  =7  e*  and  ft  F  b  e  [  r  =7  e*  are  basically  the  same  as  that  of  the 

judgements  given  in  Figure  4.9  and  Figure  4.10. 

The  following  theorem  justifies  the  correctness  of  these  rules. 

Theorem  5.2.6  We  have  the  following. 

1.  If  ft  T  b  e  |  t  =7  e*  is  derivable,  then  ftT  \~  e*  :  t  is  derivable  and  |e|  =  |e*|. 

2.  If  ftT  b  e  i  t  =7  e*  is  derivable,  then  ftT  \~  e*  :  t  is  derivable  and  |e|  =  |e*|. 

Proof  The  proof  is  parallel  to  that  of  Theorem  4.2.2.  (1)  and  (2)  follow  straightforwardly  from  a 
simultaneous  structural  induction  on  the  derivations  V  of  ft,  T  b  e  |  t  =7  e*  and  ft  F  b  e  [  r  =7  e*. 
We  present  a  few  cases. 
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6;  T  h  e  |  Ila  :  7 .r  7  e*  (/>  b  :  7 


(/>;  T  b  e  |  r[a  1— >  i]  7  e* [i] 

(j>,  a  :  7;  T  b  e  j  r  7  e* 
i>;  T  b  e  |  Ila  :  7 .r  7  (Aa  :  7-e*) 

<f>,  a  :  7;  T  b  e  j  r  7  e* 


(elab-pi-elim) 


i;  T  b  Aa  :  7-e  j  Ila  :  7.T  7  (Aa  :  7-e*) 
</>;  T  b  e  |  r[a  1 — ^  z]  =7  e*  <f>  b  i  :  7 


(elab-pi-intro-1) 
(elab-pi-intro-2) 


f>;  T  b  e  |  Xa  :  7.T  7  (i  \  e 

r(x)  =  t  4>\-  r[ctx] 


(elab-sig-intro) 


^  T  h  1  |  r  7  x 

^rhxt  7  7e*  <f>\-  coerce(ri, r2)  7  E 

<t>;  T  b  x  i  t2  7  -E[e*] 

5(c)  =  Ilai  :  71 . . .  IIan  :  7 n.<5(i)  (j)  b  n  :  71  •  •  •  (f>  b  in  :  7„ 


</>;T  b  c  T  5(i[ai, . .  .  ,an  (->•  *i, . .  5n])  7  c[n] . . .  [zn] 
<j>\  r  b  c  T  $(*)  =7  e*  0  |=  i  =  j 


(elab-var-up) 

(elab-var-down) 

(elab-cons-wo-up) 


<>-,T  \- c  l  6(j)  =>  e* 


(elab-cons-wo-down) 


5(c)  =  Ilai  :  71  . . .  na„  :  7n.r  — >  5(i) 

(j)]T  e  i  T[ai, . . .  ,an  n, . .  =7  e* 

</>  b  ii  :  71  •  •  •  (/>  b  in  :  7n 

0;  r  b  c(e)  t  <K*[ai,  •  •  •  ,a„  ^  *1? . .  .*„])  =7  c[*i]  . . .  [in](e*) 
0;  T  b  c(e)  T  £(*)  7-e*  <t>  \=  i  =  j 


(elab-cons-w-up) 


0;  T  b  c(e)  J,  <5(j)  7  e* 

</>;F  b  ()  r  1  7  () 


(elab-cons-w-down) 


(elab-unit-up) 


0;F  b  ()  i  1 7  () 

<j>)  r  b  e\  |  ri  7  e*  4>;  T  b  e2  T  D  7  eJj 


4>\  r  b  (ei,e2)  T  Ti  *  t2  7  (e?,e£) 

</>;  T  b  e\  |  T\  7  e*  T  b  e2  |  r2  7  e| 
0;  T  b  (ei,  e2)  |  n  *  r2  7  (e|,  e£) 


(elab-unit-down) 

(elab-prod-up) 


(elab-prod-down) 


Figure  5.3:  The  elaboration  rules  for  MLgI,S(C')  (I) 


5.2.  ELABORATION 


P  In  =>  (p*  ;<!>';  T')  b  e  [  r2  =*>  e*  (p\~  r2  :  * 


(elab-match) 


(elab-lam) 


4>;  r  b  (p  =>  e)  I  (n  r2)  (p*  =4-  e*) 

4>;  T  b  (p  e)  |  (n  r2)  (p*  =*>  e*)  </>;  T  b  ms  j  (n  r2)  ms* 

(/>;  T  b  (p  e  |  ms)  |  (ri  =4>  r2)  =4>  (p*  =>  e*  |  m-s*)  ' 

</>;  T  b  e  t  ti  e*  ^Thmsl  (77  r2)  =*>  ms* 

- - - - - - - - —  (elab-case) 

0;  r  r  (case  e  of  ms)  |  r2  =>  (case  e  of  ms  ) 

-  (elab-lam) 

(p;  I  b  (lam  x.e)  j  77  — >  r2  =>•  (lam  x  :  77  .e*) 

</>;  x  :  t  b  e  i  r2  =>•  e*  (f>  b  coerce(ri,  t)  E 

-  ( el 

4>;  T  b  (lam  x  :  r.e)  |  ri  — >  r2  (lam  xi  :  ri.let  x  =  E\x i]  in  e*  end) 

<t>\  r  I-  ei  T  n  -»•  r2  =*>  e\  &  T  b  e2  j  77  =>  e*2 

- ^;rhei(e2)TT2^e,(e,) -  (elab-app-up 

<I>;R  I-  ei(e2)  T  n  =>  e*  <f>  b  coerce(n,r2)  =>■  E1 
- 0;rhei(e2)lT2=,£[e1 -  (elab-app-do 

0;  r  I—  ei  t  S(a  :  7).  77  =^>  e*  4>,  a  :  7;  T,  x  :  ti  b  e2  |  r2  e£ 

<fi]  T  b  let  x  =  ei  in  e2  end  |  S(a  :  7)  .72  =7  let  (a  \  x)  =  e\  in  (a  |  e^)  end 

<frr  h  ei  t  S(a  :  7)  .77  e\  (f>,  a  :  7;  T,  x  :  77  b  e2  j  r2  =>-  e2  ^  j 

<p]  F  b  let  x  =  ei  in  e2  end  j  r2  =>•  let  (a  |  x)  =  ef  in  e2  end 

f  \  tL  u  [t  u*  ,  ,  u  0  \ 

*rb(flx/:„,)rT=-  (fix  f:r.u-)  (elab-BX-up) 

(p\  T,  /  :  r  b  u  {  t  rt*  0  I—  coerc e(r,  r')  =$■  E 


(elab-matches) 


(elab-lam-anno) 


(elab-app-up) 


(elab-app-down) 


(elab-let-up) 


(elab-let-down) 


(elab-fix-up) 


^rh  (fix  /  :  t.u)  [  t'  =7  let  x  =  (fix  /  :  r.u*)  in  E[x\  end 


(elab-fix-down) 


4>\  r  b  e  i  t  =>■  e* 


(elab-anno-up) 


i);  T  h  (e  :  r)  f  r  4  e* 

5>;  T  b  (e  :  r)  |  77  =>•  e*  <(>  b  coerce(ri,  r2)  =>•  E 
4>-  T  b  (e  :  r)  j  r2  £[e*] 


(elab- anno- down) 


Figure  5.4:  The  elaboration  rules  for  ML?’S(C7)  (II) 
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4>]  r  b  ei  t  T\  — i >  T2  =>  e\  4>;  T  b  e2  |  n  e2 

4>\  r  b  ei(e2)  T  T2  e^e?;)  Then  by  induction  hypothesis,  both  T  b 

ef  :  T\  — >  T2  and  4>;  V  b  :  t\  are  derivable.  This  leads  to  the  following. 


0;  T  b  e\  :  n  — >  r2  </>;  T  b  eJj  :  n 
(/>;T  b  e£(e£)  :  r2 


(ty-app) 


Note  |ej  (ea)  |  =  l^il  (le2l)  —  I ei  I  ( I  e2 1 ) ,  and  we  are  done. 


4>;  T  b  ei(e2)  |  Ti  e*  4>  ^  coerce(ri,  r2)  =>  E 

</>;  T  b  ei(e2)  j  72  i£[e*]  Then  by  induction  hypothesis,  </>;  T  b  e*  : 

T\  is  derivable  and  \e*\  =  |ei(e2)|.  Since  0  b  coerce(ri, 72)  =>  E  holds,  0; T  b  i£[e*]  :  T2  is 
derivable  by  Theorem  5.2.4  and  \e*\  =  |£,[e*]|.  Hence,  | ei (62) |  =  |i£[e*]|  and  we  are  done. 


<fi;  r  b  e\  t  E(a  :  j).T\  ^  e\  </>,  a  :  7;  T,  x  :  t\  b  e2  T  D  =>  e2 

(j)-,  T  b  let  x  =  e\  in  e2  end  f  E(a  :  7) .72  =>■  let  (a  |  x)  =  in  (a  |  e£)  end  By  induction  hy¬ 
pothesis,  both  </>;  T  b  e*  :  E(a  :  7).ri  and  0,  a  :  7;  T,  x  :  t\  b  e2  :  T2  are  derivable.  Hence, 

4>,  a  :  7;  T,  x  :  T\  b  e2  :  E(a  :  7)  .72  is  also  derivable  by  applying  the  rule  (trule-sig- intro) 
repeatedly.  Then  by  Proposition  5.2.2,  the  following  is  derivable. 

4>]T  b  let  (a  \  x)  =  e\  in  e*2  end  :  E(a  :  7)  .72 
Note  that  we  have  the  following. 

| let  (a  |  x)  =  e\  in  e2  end|  =  let  x  =  \e\\  in  | |  end  =  let  x  =  |ei|  in  1 62 1  end 
Hence  we  are  done. 


<t>‘,  T  b  e\  t  E(a  :  7).Ti  e\  4>,  a  :  7;  T,  x  :  T\  b  e2  |  r2  e2 

(j)-,  T  b  let  x  =  e\  in  e2  end  j  72  =$■  let  (a  |  x)  =  e\  in  e2  end  By  induction  hypothesis,  both 

f);Tbej  :  E(a  :  7).ti  and  <fi,  a  :  7;  T,  x  :  T\  b  e2  :  T2  are  derivable.  Therefore,  the  following  is 
derivable  by  Proposition  5.2.2. 

</>;  P  b  let  (a  |  x)  =  e\  in  e2  end  :  72 
Note  that  we  have  the  following. 

| let  (a  |  x)  =  e\  in  e2  end|  =  let  x  =  \e\\  in  | |  end  =  let  x  =  |ei|  in  | e2 1  end 
Hence  we  are  done. 


4>;  T,  /  :  r  b  u  j  r  =>-  u* 

(j)',T  b  (fix  /  :  t.u)  |  t  =$■  (fix  /  :  t.u*)  By  induction  hypothesis,  (j)\  T,  /  :  r  b  u*  :  r  is 
derivable.  This  yields  the  following  derivation. 


:  t  b  u*  :  t 

4>;  T  b  (fix  /  :  t.u*)  :  r 


(ty-fix) 


Also  we  have  |fix  /  :  t.u* \  =  fix  f-\u*\  =  fix  f.\u\  =  |fix  /  :  t.u |.  This  concludes  the  case. 


All  other  cases  can  be  handled  similar. 
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5.2.3  Elaboration  as  Constraint  Generation 

n  e 

As  usual,  there  is  still  a  gap  between  the  description  of  elaboration  rules  for  ML0  ’  (C)  and  an 
actual  implementation.  In  order  to  bridge  the  gap,  we  list  the  constraint  generation  rules  in 
Figure  5.5  and  Figure  5.6. 

n  s 

The  correctness  of  the  constraint  generation  rules  for  ML0  ’  (C)  is  justified  by  the  following 
theorem,  which  corresponds  to  Theorem  4.2.5. 

Theorem  5.2.7  We  have  the  following. 

1.  Suppose  that  T  F  e  |  r  =>['(/’]  is  derivable.  If  <f[6\  |=  $[0]  is  provable  for  some  6  such  that 
(f>  >  9  :  if  is  derivable,  then  there  exists  e*  such  that  </>[$];  r[$]  F  e  |  t[9\  =>  e*  is  derivable. 

2.  Suppose  that  4>]T  F  e  j  r  =>[if\  $  is  derivable.  If  4>[0\  \=  $[0]  is  provable  for  some  6  such  that 
(j>  >  9  :  ip  is  derivable,  then  there  exists  e*  such  that  </>[(?];  r[0]  F  e  j  t[9\  e*  is  derivable. 

Proof  (1)  and  (2)  are  proven  simultaneously  by  a  structural  induction  on  the  derivations  T>  of 
T  F  e  |  t  =^['0]  ‘h  and  T  F  e  j  r  4>.  The  proof  is  parallel  to  that  of  Theorem  4.2.5.  We 
present  a  few  cases. 

r,  x  :  n  F  e  i  T2  =>[V>]  T 

<f\  T  F  (lam  x.e)  j  T\  —>■  T2  =^[V’]  $  By  induction  hypothesis,  0[0];  r[0],  x  :  t\[9]  h  e  j 
t\Q\  =>  e*  is  derivable,  and  this  yields  the  following. 

_ m^[0lx-Ti[e\L  elT\6\^e* _ 

<f>[6]-,r[0]  F  (lam  x.e)  |  n[0]  ->•  r[0]  4lami:  n[0].e*  ^  ’ 

Note  that  (ri  — >  t)[6\  is  t\{9\  — ►  r[0],  and  we  are  done. 


</>;  T  h  ei(e2)  T  Ti  =^1]  $1  (0  |  ^2)  F  r2  :  * 

(cf>  |  ■02,V’i)  F[-]  coerce(n,  r2)  <h2 

(/>;  T  h  ei(e2)  j  r2  =^-[^2]  3(^i).$i  A  <h2  Note  that  A  <h2)[0]  is  Bip.&i [0]  A 

<I)2  [0] .  Hence,  there  is  an  existential  substitution  9\  such  that  <f>[6\  F  0\  \>  f>\  holds  and 
1 i>[9^\  |=  $i[02]  A  <h2[02]  is  derivable  for  02  =  9, 9\.  Hence,  </>[02]  |=  $i[02]  and  </>[02]  |=  $2[02] 
are  derivable.  By  induction  hypothesis,  0[02];  r[02]  h  ei(e2)  |  ti[02]  A>  e*  is  derivable.  Also 
f>[9-2\  F  coerce(ri[02],  r2[02])  E  is  derivable  for  some  E  by  Theorem  5.2.5.  This  leads  to 
the  following. 


0[02];  r[02]  h  ei(e2)  |  ti[02]  =7-  e*  <f[9-2\  F  coerce(ri[02],r2[02])  =7-  E 
^02];r[02]Fei(e2)|^[02]=J-^[e*] 


(elrule-app-down) 


Note  that  cj)[9]  =  </>[02],  T[0]  =  r[02]  and  r2[0]  =  r2[02],  and  |ei(e2)|  =  |e*|  =  |£,[e*]|.  Hence, 
we  are  done. 


0;  T  F  ei  t  £(a  :  7)-ri  =4^]  $1 
<f>,  af’  :  7;  T,  x  :  n[a  a^]  F  e2  f  r2  =>[ip ]  <h2 

</>;  T  F  (let  x  =  ei  in  e2  end)  f  S(aF  :  7).r2  =7>[^]  $1  A  V(a^  :  7).4>2  Then  by  assumption, 
the  following  is  derivable. 


m  |=(TiAV(oF).$2)[0] 
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0;  r  1-  e  t  T  $  (0  I  ip)  7  : 


4>;  T  h  e  |  t  =^[V>,  A  :  7]  $ 
i>;  T  h  e  |  Ila  :  7  .r  =7>[-f/>]  4> 


(constr-weak) 


(/>;  T  h  e  |  r[a  A]  =^[V’,  A  :  7]  $ 


(constr-pi-elim) 


4>,  oft  :  7;  T  b  e[a  1— ►  a^]  j  r  =^[-0]  $  (0  |  ip)  h  T[ctx] 


4>;  T  b  Aa  :  7-e  j  Ila  :  7.T  =^[^>]  V(a^  :  7).$ 
<p,  :  7;  T  h  e  j  r  =7[-0]  $  (0  |  ■0)  I—  T[ctx] 


(/)-,  T  b  e  |  Ila  :  7 .r  =>[V>]  V(a^  :  7).$ 

cp;  T  h  e  |  r[a  1— >  ^4]  =^['0,  ^4  :  7]  <!> 
4>;  T  h  e  |  Xa  :  7.T  =>[V>]  3^4  :  7.$ 

r(x)  =  t  (p  \  ip)  \-  r[ctx] 


(constr-pi-intro-l) 
(constr-pi-intro-2) 


(const  r-sig-intro) 


ri-xtr  =>[v>]  T 


(constr-var-up) 


0;  r  h  X  T  Ti  =^2,  Vh]  T  (</>  I  ^2)  1“  t-2  :  * 

(0  I  ip2)  1“  r[ctx]  ((/>  I  ip2,ipi)  !-[•]  coerce(r1,r2)  =*>  <f> 
</>;  F  1-  x  I  r2  =^2]  3(^i). 4> 

5(c)  =  II(a  :  7 )-5(z)  <p  h  Tfictx] 


(constr-var-down) 


4>]  r  h  c  |  <5(i[a  1— >  ^4])  =>[A  :  7]  T 

</>;  r  1-  c  t  £Qi)  =KV>2,  Vh]  t  |  y>2)  i~  :  * 

0;  r  b  c  I  S(i2)  =>[^2]  3(V»i).<5(ii)  =  S(i2) 

S(c )  =  II(a  :  j).t  —>  5(i)  </>;  T  h  e  j  r[a  1— >  A]  =>[V>,  A  :  7]  $ 


(f>;  T  b  c(e)  |  <5(i[a  1— >  A])  =>[ip,  A  :  7]  $ 

</>;  r  I-  c(e)  t  <5(n)  =>[^2,^1]  $ 

(P  I  ip2)  1-  d(i2)  :  *  (p  \^2)L  r[ctx] 

(j);T  \~  c(e)  i  S(i2)  =>[ip2]  3(V’i).4>  A  5(h)  =  S(i2 ) 

OH  VO  i-  rtctx] 


(constr-cons-wo-up) 

(constr-cons-wo-down) 

(const  r-cons-w-up) 


(const  r-cons-w-down) 


&rh()T  i=s#]  T 
(</>  I  VO  •“  rtctx] 


(const  r-unit-up) 


V>;  r  h  ()  1 1  =^]  t 
P]  r  1-  ei  t  n  =>[ip]  $1  <j>;  r  1-  e2  T  t2 


(constr-unit-down) 

[V’]  $2 


P‘,  T  3  (ei,  e2)  |  n  *  r2  =»[H  4>i  A  <h2 

V>;  r  h  ei  I  n  =>[V>]  4>i  </>;  T  h  e2  j  r2  =>[H  <f>2 
V>;  r  h  (ei,  e2)  I  Ti  *  r2  =>[V>]  4>i  A  $2 


(const  r-prod-up) 


(const  r-prod-down) 


n  s 

Figure  5.5:  The  constraint  generation  rules  for  ML0  ’  ( C )  (I) 
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pln=>  (jp*\4>  i;Ti)  4>,4>i\T,Ti  \-  e{  r2  =00]  $ 
(0  |  0)  h  ri  =7>  T2  :  *  (0  |  0)  b  r[ctx] 


0;  T  h  (p  =*>  e)  |  (n  =7-  r2)  =00]  V(0f).$ 

0;  T  b  (p  =^>  e)  J.  (n  =>-  r2)  =00]  <&i  ^Th  ms  |  (n  =7-  r2)  =00]  $2 
0;  T  b  (p  e  |  ms)  |  (n  =7-  r2)  =00]  $i  A  <h2 

0;  T  b  e  |  n  =00]  0;  T  b  ms  j  (n  =7-  r2)  =00]  $2 

0;  r  b  (case  e  of  ms)  j  r2  =>['0]  $i  A§2 

0;  r,  X  :  Ti  h  e  J.  r2  =00]  $ 

0;  T  b  (lam  x.e)  |  T\  — ►  r2  =00]  $ 

0;  T,  x  :  t  b  e  j  t2  =00]  $  0;  T,  x  :  n  b  x  j  r  =00]  $i 

0;  T  b  (lam  x  :  r.e)  j  T\  — »  r2  =00]  $  A  $i 

0;  r  I-  ei  t  n  — >  r2  =00]  <f>i  0;  T  b  e2  j  n  =00]  <f>2 
0;  T  h  ei(e2)  |  t2  =00]  $1  A  <h2 


(constr-match) 

(constr-matches) 
(constr-case) 


(constr-lam) 

(const  r-  lam-  anno) 
(const  r-app-up) 


0;  r  h  ei(e2)  |  n  =002, 0i]  $1  (0  |  02)  1“  t2  :  * 

(0  |  02)  h  T[ctx]  (0  |  02,0i)  b[-]  coerce(n,r2)  =7>  <f>2 

0;  T  h  ei(e2)  j  r2  =002]  3(0i).$i  A  <f>2 
0;  r  1-  ei  T  £(a  :  7)-ri  =00]  $1 

0,  :  7;  T,  x  :  n [a  i-»  a^’]  b  e2  |  r2  =00]  <h2 


(constr-app-down) 


(constr-let-up) 


0;T  b  (let  x  =  e\  in  e2  end)  \  £(«0  :  7 ).r2  =00]  $1  A  V(a0  :  7). $2 

( const  r-  let-  down) 


0;  r  h  ei  t  £(a  :  7)-n  =00] 

0,  a0  :  7;  T,  x  :  Ti  [a  i->-  a^]  b  e2  j  r2  =00]  <h2 


0;  r  b  (let  x  =  ei  in  e2  end)  j  r2  =00]  $1  A  V(a^  :  7).$2 
0;T,/  :  r  h  u  i  t  =00]  $ 


0;  T  b  (fix  /  :  r.it)  |  t  =00]  $ 
r,  /  :  r  b  u  I  r  =00]  $  0;  T,  x  :  r  b  x  J.  n  =00]  <&i 


0;  T  h  (fix  /  :  r.tt)  |  Ti  =00]  <&  A  $1 
0;  r  h  e  I  r  =00]  $ 


( const  r- fix- up) 

(constr-fix-down) 


0;  T  h  (e  :  r)  |  r  =00]  $ 


(constr-anno-up) 


0;  r  h  (e  :  r)  t  n  =00]  T  (0  |  0)  b  r2  :  * 

(0  |  0)  b[-]  coerce(ri,  r2)  =7>  $ 

0;  r  h  (e  :  r)  I  r2  =00]  $ 


(constr-anno-down) 


n  s 

Figure  5.6:  The  constraint  generation  rules  for  ML0  ’  (C)  (II) 
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This  implies  that  both  <j>[d\  b  $i[0]  and  < j>[9\  b  V(a^  :  7[0]).3>2[0]  are  derivable.  By  induc¬ 
tion  hypothesis,  the  following  is  derivable  for  some  e\  such  that  \e\\  =  |ej | ,  where  y[0]  is 
7i [0\,  ■  •  •  ,7 n[0\  for  7  =  7i>  •  •  •  > 7n- 

#];r[0]he1TE(a^:#]).r1[^el 

Notice  that  the  derivability  of  <f)[9]  b  V(a^  :  7[0]).$2[0]  implies  that  of  4>[9],a^  :  y[0]  |=  $2 [#]• 
By  induction  hypothesis,  we  have  the  following  derivable  for  some  e\  such  that  |e2 1  —  le^l- 

0[0],o^[0]  :  7[0];T[0],x  :  n[ai->  a^][0]  b  e2  T  d[9]  =>  e2 

This  yields  the  following  derivation. 

#?];T[0]bei  TS(a:7[0]).r1[0]^et 
0[0] ,  :  7 [0] ;  T,  x  :  ri  [a  a^]  [0]  b  e2  T  i"2  [0]  =>-  e2 

0[0];T[0]  b  let  x  =  ei  in  e2  end  f  S(a^  :  7[0]).72[0]  =7-  let  (a  |  x)  =  e\  in  (a  |  e^}  end 
So  the  case  wraps  up. 

_  0;  r,  /  :  r  b  u  I  r  =7>[^]  T 

</>;T  b  (fix  /  :  t.u)  |  r  =>[V>]  $  By  induction  hypothesis,  0[0];T[0],  /  :  t[0]  b  «  |  t[9 ]  =7- 
u*  is  derivable  for  some  u*  such  that  |it|  =  |u*|,  and  this  leads  to  the  following. 

(j)[d\;T[e\,  f  :  t[9\  b  u  j  t[9\  =»  u* 

#?];T[0]  b  (fix  /  :  r.u)  I  t[9]  =7  (fix  /  :  r[0].u*)  1  J 

Note  that  |fix  /  :  r.«|  =  fix  /.|u|  =  fix  f.\u*\  =  (fix  /  :  t[9].u* |,  and  we  are  done. 

All  other  cases  can  be  treated  in  a  similar  manner.  ■ 

Given  a  program,  that  is,  a  closed  expression  e  in  DML((7),  we  can  use  the  constraint  generation 

rules  to  derive  a  judgement  of  form  b  e  j  r  =>[-0]  $  for  some  ?/>,  r  and  $.  Assume  that  this 

process  succeeds.  By  Theorem  5.2.7  and  Theorem  5.2.6,  we  know  that  e  can  be  elaborated  into  an 

n  s 

expression  e*  in  ML0  ’  (C)  such  that  |e|  =  |e*|  if  •  j=  3(-0) .<!>  can  be  derived.  In  this  sense,  we  say 

n  s 

that  type-checking  in  ML0  ’  ( C )  has  been  reduced  to  constraint  satisfaction. 


5.3  Summary 

In  this  section,  ML^((7)  is  extended  with  existential  dependent  types,  leading  to  the  language 
ML^^C).  This  extension  seems  to  be  indispensable  in  practical  programming.  For  instance, 
existential  dependent  types  are  used  in  all  the  examples  presented  in  Appendix  A.  Like  ML^(C), 

ML^^C)  enjoys  the  type  preservation  property  and  its  operational  semantics  can  be  simulated 

n  s 

by  that  of  MLo  (Theorem  5.1.3  and  Theorem  5.1.5).  Consequently,  ML0  ’  (C)  is  a  conservative 

extension  of  MLo- 

n  s 

ML0  ’  (C)  is  an  explicitly  typed  internal  programming  language,  and  therefore,  a  practical 

ns  ns 

elaboration  from  the  external  language  DML(C)  to  ML0  ’  (C)  is  crucial  if  ML0’  ((7)  is  intended 
for  general  purpose  programming.  As  for  ML^((7),  we  achieve  this  by  presenting  a  set  of  elaboration 
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rules  and  then  a  set  of  constraint  generation  rules.  The  correctness  of  these  rules  is  justified  by 

Theorem  5.2.6  and  Theorem  5.2.7,  respectively. 

However,  there  is  a  significant  issue  which  involves  whether  a  variant  of  A-normal  transform 

n  s 

should  be  performed  on  programs  in  ML0  ’  (C)  before  elaboration.  This  transform  enables  us 
to  elaborate  a  very  common  form  of  expressions  which  could  otherwise  not  be  elaborated,  but  it 
also  prevents  us  from  elaborating  a  less  common  form  of  expressions.  A  serious  disadvantage  of 
performing  the  transform  is  that  it  can  complicate  reporting  comprehensible  error  messages  during 
elaboration  since  the  programmer  may  have  to  understand  how  the  programs  are  transformed.  An 
alternative  is  to  allow  the  programmer  to  control  the  transform  with  the  help  of  some  sugared 
syntax.  This  has  yet  to  be  settled  in  practice.  We  point  out  that  the  transform  is  performed  in 
our  current  prototype  implementation. 

This  chapter  has  further  solidified  the  justification  for  the  practicality  of  our  approach  to 

extending  programming  languages  with  dependent  types.  The  theoretic  core  of  this  thesis  consists 

n  s 

of  Chapter  4  and  Chapter  5.  We  are  now  ready  to  study  the  issues  on  extending  ML0  ’  (C)  with 
let-polymorphism,  effects  such  as  references  and  exceptions,  aiming  for  adding  dependent  types  to 
the  entire  core  of  ML. 
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Chapter  6 

Polymorphism 


Polymorphism  is  the  ability  to  abstract  expressions  over  types.  Such  expressions  with  universally 

quantified  types  can  then  assume  different  types  when  the  universally  quantified  type  variables  are 

instantiated  differently.  Therefore,  polymorphism  provides  an  approach  to  promoting  certain  form 

of  code  reuse,  which  is  an  important  issue  in  software  engineering.  In  this  chapter,  we  extend  the 

language  MLo  to  MLq  with  ML-style  of  let-polymorphism  and  prove  some  relevant  results.  We  then 

n  s  w  n  s 

extend  the  language  MLq  ’“'(C)  to  MLq  ’(C),  combining  dependent  types  with  let-polymorphism. 
The  relation  between  MLq^’^C)  and  MLq  is  established,  parallel  to  that  between  MLq  :S(C)  and 
ML0. 

Although  the  development  of  dependent  types  is  largely  orthogonal  to  polymorphism,  it  is 
nonetheless  noticeably  involved  to  combine  these  two  features  together.  Also  there  are  some  prac¬ 
tical  issues  showing  up  when  elaboration  is  concerned,  which  must  be  addressed  carefully. 

6.1  Extending  MLq  to  MLq 

In  this  section,  we  extend  MLo  with  ML-style  of  let-polymorphism,  yielding  a  polymorphic  pro¬ 
gramming  language  MLq.  The  syntax  of  MLq  enriches  that  of  MLq  with  the  following. 


type  variables 

a 

type  constructors 

6 

types 

t  : 

:=  •  •  •  |  a\ 

Tl,  •  •  •  i  T~ri)d 

type  schemes 

<7  : 

:=  t  Va.cr 

patterns 

P 

:=  •  •  •  |  c(a) 

1  c(a)(p) 

expressions 

e 

■=  •  •  •  c(^) 

1  c(f)(e)  |  x(t) 

Aa.e 

value  forms 

u 

:=  •••  c(r) 

1  c(r)(u) 

values 

v  : 

:=  •  •  •  |  x(t 

1  c(f)  |  c(t)(v) 

Aa.v 

type  var  contexts 

A  : 

:=  ■  A,  a 

signature 

«S  : 

:=  ■■•|S,<y 

:*—»••••  —>  * 

c  :  Va.(a)S 

substitutions 

6  : 

:=  •  •  •  |  9\a 

h->  t] 

We  use  t  for  a  (possibly  empty)  sequence  of  types  t\,  ...  ,rm.  In  addition,  given  t  =  t\,  ...  ,Tm, 
(• t)S ,  c(t)  and  x(t)  are  abbreviations  for  (n, . . . ,  Tm)S,  c(ti)  . . .  (rm)  and  x(t\)  . . .  (rm),  respectively. 
We  may  also  write  Va.a  for  Vaq  . . .  Van.<j,  where  a  =  aq, . . . ,  an. 
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a  £  A 
Aha:* 

S(S)  =  *  — >  •  •  •  — ►  * 


(type-var) 


Ah  /3  :  * 

*  A  h  rj  :  *  •••  A  h  rm  :  » 


A  h  (n, . . .  ,Tm)S  :  * 

A  b  n  :  *  A  h  T2  :  * 


(type-unit) 


A  h  1  :  * 

A  b  n  :  *  Ah  T2  :  * 
A  b  n  —*  T2  :  * 


(type-fun) 


Ah  T\  *  T2  :  * 

A,  ah  a 


(type-base) 

(type-datatype) 
(type-prod) 
(type-poly) 


A  b  Va.cr 


Figure  6.1:  Type  formation  rules  for  MLq 

The  types  in  MLq  are  basically  those  defined  in  MLo  but  they  may  contain  type  variables  in 
this  setting.  A  type  scheme  a  must  be  of  the  form  Vaq  •  •  •  Va„.r  and  a  is  t  if  n  =  0. 

Notice  that  the  treatment  of  patterns  is  non-standard.  In  ML,  the  type  variables  do  not  occur 
in  patterns.  We  take  this  approach  since  it  naturally  follows  the  one  we  adopted  for  handling 
universal  dependent  types  in  Section  4.1.  However,  the  difference  is  largely  cosmetic. 

6.1.1  Static  Semantics 

The  rules  for  forming  legal  types  in  MLq  are  presented  in  Figure  6.1.  Clearly,  if  A  b  a  :  *  is 
derivable,  then  all  free  type  variables  in  a  are  declared  in  A. 

We  present  the  typing  rules  for  pattern  matching  in  Figure  6.2.  We  then  list  all  the  type 
inference  rules  for  MLq  in  Figure  6.3.  Of  course,  we  require  that  there  be  no  free  occurrences  of 
a  in  F(x')  for  every  x  £  dom(r)  when  the  rule  (ty-poly- intro)  is  introduced.  The  rules  closely 
resemble  those  for  MLo  except  that  we  now  use  a  type  variable  context  A  in  every  judgement 
to  keep  track  of  free  type  variables.  The  let-polymorphism  is  enforced  because  (ty-let)  is  the 
only  rule  which  can  eliminate  from  (ordinary)  variable  context  the  variables  whose  types  contain 
V  quantifiers. 

Given  a  substitution  6,  we  define 


x{t)[6\  =  v[a  i— >  r] 

if  6(x)  =  A a.v.  Notice  that  a  and  r  must  have  the  same  length.  Otherwise,  x(f)[Q\  is  unde¬ 
fined.  This  definition  obviates  the  need  for  introducing  expressions  of  form  e(r)  for  non-variable 
expressions  e,  which  cannot  occur  in  MLq  since  only  let-polymorphism  is  allowed. 

Lemma  6.1.1  If  A  b  r*  :  *  are  derivable  for  i  =  1  ,...,n  and  A,a;r  b  e  :  a  is  also  derivable 
in  MLq,  then  A;r[d  e- s>  r]  b  e[a  >— >  r]  :  cr[a  ex-  r]  is  derivable,  where  a  =  ai,...,an  and 

T  =  Tl,  .  .  .  ,  Tn. 

Proof  This  simply  follows  from  a  structural  induction  on  the  derivation  of  A,5;T  h  e  :  a.  ■ 
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Figure  6.2:  Typing  rules  for  pattern  matching  in  MLq 


Lemma  6.1.2  If  both  A;  T  b  v  :  <J\  and  A;  T,  x  :  a\  h  e  :  a  are  derivable,  then  A;  T  h  e[x  i— >  u]  :  a 
is  also  derivable. 


Proof  This  simply  follows  from  a  structural  induction  on  the  derivation  of  A;  T,  x  :  a\  h  e  :  a.  ■ 


6.1.2  Dynamic  Semantics 

The  evaluation  rules  for  formulating  the  natural  semantics  of  MLq  are  those  for  MLo  plus  the 
following  rule  (ev-poly),  which  is  needed  for  evaluation  under  A. 


Note  that  we  do  not  need  a  rule  for  evaluating  e(r)  because  this  expression  can  never  occur  in 
MLq. 

As  usual,  the  type  preservation  theorem  holds  in  MLq. 

Theorem  6.1.3  (Type  preservation  for  MLq,)  If  e  c— >o  v  and  A;T  h  e  :  a  are  derivable,  then 
A;  T  h  v  :  a  is  also  derivable. 


Proof  This  proof  proceeds  by  a  structural  induction  on  the  derivation  V  of  e  c— >o  v,  parallel  to 
that  of  Theorem  2.2.7.  We  present  several  cases. 

ei  vi  e2[x  Vi]  ^ 0  v 
V  = - ; - 

(let  x  =  e\  in  e2  end)  ^q  v  Then  we  also  have  the  following  derivation. 


A;  T  h  ei  :  <Ti  A;  T,  x\  :  o\  h  e2  :  r 

— t  — — — - ; - - -  (ty-let 

A;  1  r  let  x\  =  e±  in  e2  end  :  r 
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A  h  Ti  :  * 


A\~  Tn  :  *  r(x)  =  Vai  •  •  •  Van.r 


A;  T  b  x(n) . . .  (rn)  :  r[a i, . . . ,  an  n, . . . ,  rn\ 

5(c)  =  Vai  •  •  •  Van.(ai, . . . ,  an)6  A  b  n  :  *  •••  A  b  rn  :  * 

A;  T  b  c(r i,  ...,Tn):  (n, . .  .,rn)5 
5(c)  =  Vai  •  •  •  Van.T  — >  5 

■  A  b  r„  :  »  A;rbe:r[air..,Q„Hri,...,r„] 


(ty-poly-var) 

(ty-poly-cons-wo) 


A  b  n  :  * 


A;  r  b  c(ti,  . . . ,  rn)(e)  :  (n, . ... ,  rn)5 

— — — - - -  (ty-unit 

A;T  b  ()  :  1  v  J 

A;  T  b  ei  :  Ti  A;  T  b  e2  :  r2 

A;  T  b  (ei,e2)  :t1*t2 

A  b  n  :  *  p  |  T\  t>  T'  A;  T,  T'  b  e  :  r2 


(ty-poly-cons-w) 


(ty-prod) 


A;  r  b  (p 


A;  T  b  p  e  :  T\  r2 
e)  :  ri  r2  A;  T  b  ms  :  T\ 


(ty-match) 


t2 


A;  T  b  (p  e  |  ms)  :  ri  r2 
A;  T  b  e  :  Ti  A;  T  b  ms  :  T\  r2 


(ty-matches) 


A;  T  b  (case  e  of  ms)  :  t2 
A;  T,  x  :  T\  b  e  :  r2 
A;  T  b  (lam  x  :  ri.e)  :  ri  — ^  r2 
A;  T  b  ei  :  ri  r2  A;  T  b  e2  :  t\ 
A;  T  b  ei(e2)  :  r2 
A;  T  b  ei  :  a  A;  T,  x  :  a  b  e2  :  r 
A;  r  b  let  x  =  ei  in  e2  end  :  r 
A ;  r,  /  :rb«:r 


(ty-case) 


(ty-lam) 

(ty-app) 

(ty-let) 


A;  T  b  (fix  /  :  r.ti)  :  r 
A,  a;  T  b  e  :  a 


(ty-fix) 


A;  T  b  Aa.e  :  Va.cr 


(ty-poly- intro) 


Figure  6.3:  Typing  Rules  for  MLn 
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By  induction  hypothesis,  A;  V  b  v\  :  a\  is  derivable.  Therefore,  A;T  b  e2[xi  i— >  ui]  :  r  is 
derivable  by  Lemma  6.1.2.  This  leads  to  a  derivation  of  A;  T  b  v  :  a\  by  induction  hypothesis. 


ei  ^->0  Vi 

V  = - 

Aa.ei  c— >o  A.a.vi  Then  we  also  have  the  following  derivation. 


A,  a;  T  h  ei  : 

A;  T  h  Aa.ei  :  Va.cri 


(ty-poly-intro) 


By  induction  hypothesis,  •;  A,  a;  T  b  v\  :  o\  is  derivable.  This  readily  leads  to  a  derivation  of 
A;T  h  Ka.v\  :  Va.cr i. 


As  in  MLo,  types  play  no  role  in  program  evaluation.  Extending  the  definition  of  the  type 
erasure  function  |  •  |  as  follows,  we  capture  the  indifference  of  types  to  evaluation  in  MLq  through 
Theorem  6.1.4. 

\x(t)\  =  x  |c(a)|  =  c  |c(a)(e)|  =  c(|e|)  |Aa.e|  =  |e| 

Theorem  6.1.4  Given  an  expression  e  in  MLq,  we  have  the  following. 

1.  If  e  c — >o  v  is  derivable  in  MLq  ,  then  \e\  M  is  derivable  in  Aj^. 

2.  If  A;  T  h  e  :  cr  is  derivable  in  MLq  and  \e\  vq  derivable  in  A^*,  then  e  c— >o  v  is  derivable 
in  MLq  for  some  v  such  that  |u|  =  vq. 

Proof  (1)  and  (2)  follow  from  a  structural  induction  on  the  derivations  of  e  c— >o  v  and  |e|  v0i 
respectively.  ■ 

We  have  now  finished  setting  up  the  machinery  for  combining  dependent  types  with  the  ML 
style  of  let-polymorphism. 

6.2  Extending  ML^’S(C)  to  MLo’n,E(C') 

n  s  v  n  s  _ * 

The  language  MLq ’(C)  is  extended  to  the  language  MLq  ’  (C)  as  follows.  We  use  i  for  a  (possibly 

empty)  sequence  of  type  indices.  In  addition,  given  t  =  t\,  . . .  ,rm  and  i  =  i\, . . . ,  in ,  c(a)[ij  is  an 

abbreviation  for  c(ti)  . . .  (rm)[i i]  . . .  [in]. 

type  variables  a 

types  r  ::=  •  •  •  |  a 

type  schemes  a  ::=  r  |  Va.cr 

patterns  p  ::=  ■  ■  ■  |  c(a)[i]  |  c(a 

expressions  e  ::=  ■  •  •  |  c(r)[i]  |  c(r)[ij(e)  |  x(r)  |  Aa.e 

value  forms  u  ::=  •  •  •  |  c(r)[ij  |  c(f  )[*](  u) 

values  v  ::=  •  •  •  |  x{T)  |  c(r)[i]  |  c(r)[i](u)  |  Aa.v 

signature  S  ::=  ■■■  \  S,5  :*—>■■■  — >  *  — >7— r  *  |  5, c :  Va.Va  :  'j f(a)5(i ) 

substitutions  6  ::=  •  •  •  |  6{on-^  t\ 
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Figure  6.4:  Type  formation  rules  for  MLQ’n’S((7) 

The  types  in  MLQ,n,S(C')  are  basically  the  types  defined  in  ML^^C)  but  they  may  contain 
type  variables  in  this  setting.  A  type  scheme  a  must  then  be  of  the  form  Vaq  •  •  •  Van.r  and  a  is  r 
if  n  =  0.  Notice  that  this  disallows  V  quantifiers  to  occur  in  the  scope  of  a  n  or  E  quantifier.  For 
instance,  the  following  is  an  illegal  type. 

Iln  :  natS/a.{a)list{n)  — ►  ( a)list(n ) 

This  restriction  is  also  necessary  for  the  two-phase  type-checking  algorithm  we  introduce  shortly. 

6.2.1  Static  Semantics 

We  present  the  rules  for  forming  legal  types  in  Figure  6.4. 

Also  we  need  the  following  additional  rules  for  handling  the  type  congruence  relation. 


(f>  \=  a  —  a 

<t>  |=  n  =  t[  •  •  •  (f>\  =Tn  =  T'n  0  |  =  i  =  i! 

<t>  !=  Oi,  •  •  • ,  Tn)d(i)  =  (r{, . . . ,  T'n)8{i') 

We  present  the  typing  rules  for  pattern  matching  in  Figure  6.5.  Notice  that  in  the  rule 
(pat-cons-w),  the  type  of  a  constructor  c  associated  with  a  datatype  constructor  5  is  always 
of  form 

Mai  ■  •  •  Vam.IIai  :  71 . .  .IIan  :  7 n.(r  -»•  (aq, . .  .,am)5(i)) 

For  instance,  it  is  not  allowed  in  SML  to  declare  a  datatype  as  follows, 
datatype  bottom  =  Bottom  of  ’a 

because  this  declaration  assigns  Bottom  the  type  Va.a  bottom .,  which  clearly  is  not  of  the 

required  form  Vcc.r  — ►  ( a)bottom . 

The  following  proposition  is  parallel  to  Proposition  4.1.8  for  ML^C). 

Proposition  6.2.1  We  have  the  following. 
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zirHs  —)  (pat'Var| 

0i  !>(•;•)  (pat_Unit) 


pi  I  n  >  (</>i;Ti)  p2 1  r-2  >  (02;r2) 

(pi,P2>  I  n  *  r2  >  (0i, <^2; Ti, r2)  pa  pr° 


5(c)  =  Vai . .  .Vam.IIai  :  71 . .  .IIan  :  7„.(ai, . . .  ,am)8(i) 

— — - - - ir — - - — 7— - r^T- - - r  (pat-cons-wo) 

c{a  1)  . . .  (am)[aij  . . .  [an\  j  (n, . . .  ,Tm)d(j)  D>  (a  1  :  71, . . .  ,an  :  7;  •) 

5(c)  =  Vai  . .  .Vam.IIai  :  71 . . .  IIan  :  7 n.(r  ->  (aq, . .  .,am)S(i)) 

p  |  r[ai, . . .  ,am  ho  n, . . .  ,rm]  >  (</>;T)  ^ 

c(ai) . . .  (am)[ai] . . .  [an](p)  j  (n, . . .  ,rm)5{j)  >  (ai  :  71, . . . ,  an  :  7 n,i  =  j,  0;  T)  1 


Figure  6.5:  Typing  rules  for  patterns 


!■  IH^II  =  llTll  and  lle[6']ll  =  llell[ll6'll]- 

2.  ||u||  is  a  value  form  in  MLq  if  u  is  a  value  form  in  MLg'n,S(C'). 

3.  (Ml  is  a  value  in  MLq  if  v  is  a  value  in  MLQ’n’S(C7). 

4-  If  P  I  t  >  ((/>';  T')  is  derivable,  then  ||p||  |  ||r||  t>  ||r/||  is  derivable. 

5.  //match(p,  v)  =>■  6  is  derivable  in  MLg’n’S(C'),  then  match(||p||,  ||u||)  =>  ||0||  is  derivable 
in  MLq. 

6.  Given  v,p  in  MLQ’n’S((7)  such  that  f>;  T  h  v  :  r  and  p  j  r  ==$■  (<//;  T')  are  derivable.  If 
match(||p||,  ||u||)  =7>  9q  is  derivable,  then  match(p,u)  =>■  6  is  derivable  for  some  9  and 

m  =  0o. 

7.  If  (f>  h  T\  =  r2  is  derivable,  then  ||ti||  =  1 1 to 1 1  - 


Proof  Please  refer  to  the  proof  of  Proposition  4.1.8.  ■ 

We  list  all  the  type  inference  rules  for  MLq’TI’^(Ci)  in  Figure  6.6.  The  rules  resemble  those 

n  s 

for  MLq  ’  (C)  very  closely  except  that  we  now  use  a  type  variable  context  A  in  a  judgement  to 
keep  track  of  free  type  variables.  The  let-polymorphism  is  enforced  because  (ty-let)  is  the  only 
rule  which  can  eliminate  from  (ordinary)  variable  context  a  variable  whose  type  begins  with  a  V 
quantifier. 


Example  6.2.2 

derivation, 


We  present  an  example  of  type  derivation  in  MLQ,n,S(C').  Let  T>\  be  the  following 

(ty-poly-var) 


•;  cc;  x  :  a  P  x  :  a 
:a;  ■  P  Ax  :  a.x  :  a 


a 


(ty-lam) 


•  P  (Aa.Ax  :  a.x)  :  Va.a 


a 


(ty-poly-intro) 
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0;  A;  T  h  e  :  ri  0  b  n  =  r2  ,  . 

- <#,;A;rhe:r2 -  <ty-eq) 

4>]  A  b  n  :  *  •  •  •  4>;  A  b  rn  :  *  T(x)  =  V«i  •  •  •  Van.r 

0;  A;  T  h  x(ri) . . .  (rn)  :  r[ai, . . . ,  an  n, . . . ,  Tn\ 

(/>;  A  b  n  :  *  •••  </>;  A  b  rn  :  *  5(c)  =  Vai  •  •  •  Van.r 


</>;  A;  T  b  c(n)  •  •  •  (rn)  :  r[«i, 


,  C7j  I  >  7”1 ,  .  .  .  ,  Tn] 

(ty-unit) 


(ty-poly-var) 

(ty-poly-cons) 


0;  A;  r  b  ()  :  1 
0;  A;  T  b  ei  :  n  <?5>;  A;  T  b  e2  :  r2 
</>;  A;T  b  (ei,e2)  :  n  *  r2 
p|n>  (<ft'; r7)  ^,^;r,r'be:r2 
4>;  A;  T  b  p  e  :  ri  =>■  r2 
(/>;  A;  T  b  (p  e)  :  7i  =7-  r2  0;  A;  T  b  ms  :  T\ 


(ty-prod) 

(ty-match) 

T2 


</>;  A;  T  b  (p  =>■  e  |  ms)  :  n  =7>  r2 
6;  A;  T  b  e  :  ri  </>;  A;  T  b  ms  :  t\  =>  r2 


(ty-matches) 


4>;  A;  T  b  (case  e  of  ms)  :  r2 
4>,  a  :  7;  A;  T  b  e  :  r 
(/>;  A;  T  b  (Aa  :  y.e)  :  (Ila  :  y.r) 
4>;  A;  T  b  e  :  Ila  :  7.T  (j)  b  i  :  7 


(ty-case) 


(j>\  A;  T  b  e[i]  :  r[a  e- >  i] 
i>;  A;  T  b  e  :  r[a  1 — >  *]  4>  b  i  :  7 


(ty-ilam) 

(ty-iapp) 


(j>;  A;  T  b  (i  \  e)  :  (£a  :  y.r) 

</>;  A;  T  b  ei  :  Ha  :  7.T1  4>,  a  :  7;  T,  x  :  n  b  e2  :  r2 
A;  T  b  let  (a  |  x)  =  e\  in  e2  end  :  r2 
4>]  A;  r,  x  :  T\  b  e  :  r2 
4>]  A;  r  b  (lam  x  :  n.e)  :  n  — >  r2 
0  A;  T  b  ei  :  T\  — >  r2  (j)]  A;  T  b  e2  :  n 
0;  A;  T  b  ei(e2)  :  r2 
0  A;  T  b  ei  :  a  </>,  0i;  A;  T,  x  :  cr  b  e2  :  r 


0, ;  A;  r  b  let  x  =  ei  in  e2  end  :  r 

<£;  A;  r,  /  :  r  b  a  :  r 


(ty-sig-intro) 

(ty-sig-elim) 
(ty-lam) 

(ty-app) 
(ty-let) 


4>]  A;  T  b  (fix  /  :  r.it)  :  r 
•;  A,  a;  T  b  e  :  cr 


(ty-fix) 


•;  A;  T  b  Aa.e  :  Va.a 


(ty-poly-intro) 


Figure  6.6:  Typing  Rules  for  MLn,n,S(C') 
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and  V 2  be  the  following  one, 
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•  b  int  :  * 

\/a.a  — >  a  b  0  :  int  ■;■;/:  Vcca  — >  a  b  /(int)  :  int  — >  int 
Va.a  -+ab  /( int)(0)  :  int 


(ty-poly-var) 

(ty-app) 


and  V 3  6e  the  following  one. 


•;  •  b  bool  :  * 

Va.ct  — - ►  a  b  false  :  bool  ■;•;/:  Vcca  — ►  a  b  /(bool)  :  bool  — >  bool 
•;•;/:  Vcca  ->ab  /(bool)  (false)  :  bool 


(ty-poly-var) 

(ty-app) 


Then  we  have  the  following  derivation. 


T>-2  V  3 


V i  •;  •;  /  :  Vcca  — >  a  b  (/(int)(0),  /(bool) (false))  :  int  *  bool 


•;  •  b  let  /  =  Aa.Xx  :  a.x  in  (/( int)(0),  /(bool) (false))  end  :  int  *  bool 


(ty-prod) 

(ty-let) 


Lemma  6.2.3  //</;  A  b  r*  :  *  are  derivable  for  1  =  1 ,...  ,n  and  <f>;  A,  a; T  b  e  :  <7  is  also  derivable, 
then  A; T[a  *— >  r]  b  e[a  i— ►  f]  :  <r[d  i— >  r]  is  derivable,  where  a  =  ai, . . .  ,an  and  r  =  ri, . . . , rn. 


Proof  This  simply  follows  from  a  structural  induction  on  the  derivation  of  A,  a;  T  b  e  :  a.  ■ 

Lemma  6.2.4  If  both  /;  A;  T  b  v  :  <ti  and  <j>,  0i;  A;  T,  x  :  <ri  b  e  :  a  are  derivable,  then  <p,  <j>i]  A;  T  b 
e[x  i— ►  u]  :  u  is  also  derivable. 


Proof  The  proof  follows  from  a  structural  induction  on  the  derivation  V  of  <f,  /q; A;  T,  x  :  <J\  b 
e  :  a.  We  present  one  case  as  follows. 

WfAbn:*  •••  (),()i;Abr„:* 

P  = - - - - - - - — 

4>,  f> i;  A;  T,  x  :  Va.r  b  x(t )  :  r[a  i— ►  t\  Since  </;  A;  T  b  v  :  \/a.r  is  derivable,  v  is  of  form 
Aa.vi  and  </;  A ,5;T  b  v  :  r  is  also  derivable  by  inverting  the  rule  (ty-poly-intro).  We 
require  that  a  have  no  free  occurrences  in  the  types  of  the  variables  declared  in  T.  This 
implies  that  />,  /i;  A,  a;  T  b  v  :  r  is  also  derivable. 

Notice  x(t)[x  :=  Aa.v\]  =  q[a  f].  By  Lemma  6.2.3,  />, /i;  A;T  b  v[a  >  r]  :  r[a  >  r]  is 
derivable  since  T  =  r[d  i— >  r]. 

All  other  cases  can  be  treated  similarly.  ■ 

6.2.2  Dynamic  Semantics 

n  S 

In  addition  to  the  evaluation  rules  for  ML0  ’(C),  we  also  need  the  following  rule  to  formulate  the 
natural  semantics  of  MLQ,n,S(C). 

e^dV 

Aa.e  Aa.v 


(ev-poly) 
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Theorem  6.2.5  ( Type  preservation  for  MLg’n'‘"(C')j  If  both  e  c— *• d  v  and  A;  T  b  e  :  a  are 
derivable,  then  A;  T  b  v  :  a  is  also  derivable. 


Proof  The  proof,  parallel  to  that  of  Theorem  5.1.1,  is  based  on  a  structural  induction  on  the 
derivation  V  of  e  c— ^  v  and  the  derivation  of  <f\  A;  T  b  e  :  a,  lexicographically  ordered.  We  present 
a  few  interesting  cases  as  follows. 

ei  ^ d  vi  e2[x  ui]  ^ d  v 

V  = - ; - 

(let  x  =  e\  in  e2  end)  v  Then  we  also  have  the  following  derivation. 


0;  A;  T  h  ei  :  ui  (p,  <pi]A:  L,  x\  :  a,  h  e2  :  t 
4>,  ;  A;  T  b  let  x\  =  ei  in  e2  end  :  r 

By  induction  hypothesis,  (j>\  A;  T  h  v\  :  cr \  is  derivable.  Therefore,  (j>,  f>i]  A;  V  b  e2[xi  v\]  :  r 
by  Lemma  6.2.4.  This  leads  to  a  derivation  of  4>,  0i;  A;  T  b  v  :  r. 

ei  <->d  vi 

V  - - 

Aa.ei  Aa.ui  Then  we  also  have  the  following  derivation. 


•;  A,  a;  T  b  ei  :  o\ 

•;  A;  T  b  Aa.e\  '■  Va.cri 


(ty-poly- intro) 


By  induction  hypothesis,  •;  A,  a;  T  b  v\  :  is  derivable.  This  readily  leads  to  a  derivation  of 

•;  A;  T  b  Aa.v\  :  Vq.cti 


The  rest  of  the  cases  can  be  treated  similarly. 


Clearly,  the  definition  of  the  index  erasure  function  ||  •  |j  can  be  extended  as  follows. 


la  1 

=  a 

Va.cr 

=  Va.  |<7  | 

Aa.e 

=  Aa.  e 

x(f)|| 

=  x(\\t\\) 

|c(r)[i]|| 

=  c(||t||) 

|c(f)[ij(e)|| 

QJ 

!E 

o 

II 

Now  an  immediate  question  is  whether  we  still  have  the  corresponding  versions  of  Theorem  5.1.2, 
Theorem  5.1.3  and  Theorem  5.1.5  in  MLQ,n,^(C').  Unsurprisingly,  the  answer  is  positive. 

The  relation  between  MLQ'n’S((7)  and  MLq  is  similar  to  that  between  MLjy^C)  and  MLo- 
The  following  theorem  corresponds  to  Theorem  5.1.2.  Therefore,  if  an  (untyped)  expression  in 
is  typable  in  MLQ,n,S(C'),  it  is  already  typable  in  MLq.  This  reiterates  that  the  objective  of  our 
work  is  to  assign  programs  more  accurate  types  rather  than  make  more  programs  typable. 

Theorem  6.2.6  If  (j>;  A;  T  b  e  :  a  is  derivable  mMLg’n,S(C),  then  A;  ||T||  b  ||e||  :  ||oj|  is  derivable 
in  MLq. 


Proof  The  proof  follows  from  a  structural  induction  on  the  derivation  of  \  A;  T  b  e  :  a 
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Theorem  6.2.7  If  e  c- v  is  derivable  in  MLQ,n’^(C'),  then  ||e||  ||^o||  is  derivable  in  MLq. 


Proof  This  follows  a  structural  induction  on  the  derivation  V  of  e  ► d  v.  We  present  a  few 
interesting  cases. 


ei  d  v\  e2[x  ^  ui  v 
V  = - 

(let  x  =  e\  in  e2  end)  hj®  By  induction  hypothesis,  ||ei||  c— >o  ||ui||  and  \\e2[x  i— ► 
vi]||  c — >o  |M|  are  derivable.  It  can  be  readily  verified  that  \\e2[x  i— ►  ui]||  =  || 62 1| [a?  i— >  ||ui||]. 
This  leads  to  the  following  derivation. 


gijj  INI  jMjg  >->•  IM]  l|u 

let  x  =  || ei ||  in  || e2 1|  end  Ill’ll 


(ev-let) 


Hence,  1 1  let  x  =  e\  in  e2  end||  c— >o  IMI  is  derivable. 


ei  ^->d  vi 

Aa.ei  ^d  Aa.ui  By  induction  hypothesis,  ||ei||  ||ih||  is  derivable  in  MLq.  Since 

1 1 Acr.ei 1 1  =  Aa.||ei||  and  ||Aa.ui||  =  Aa.||ui||,  || Aor.ei ||  c— ^  ||Aa.ui||  is  derivable  in  MLq. 


Theorem  6.2.8  Given  4>]T  b  e  :  a  derivable  in  MLQ,n,S(C').  If  e°  =  ||e||  ^->o  is  derivable  for 
some  v°  in  MLq,  then  there  exists  v  in  MLq  ’  (C)  such  that  e  c-» d  v  is  derivable  and  ||u||  =  u°. 

Proof  The  proof  is  similar  to  that  of  Theorem  5.1.5,  and  therefore  we  omit  it  here.  ■ 

6.2.3  Elaboration 

We  slightly  extend  the  external  language  DMLo(C')  as  follows,  yielding  the  external  language 
DML(C)  for  MLo’n’S(C). 

expressions  e  ::=  •  •  •  |  Acc.e 

Theoretically,  there  are  no  technical  obstacles  which  prevent  us  from  directly  formulating  elabo¬ 
ration  rules  and  then  constraint  generation  rules  for  ML^’^C)  as  is  done  for  MLq ’S(C).  However, 
in  practice  there  are  some  serious  disadvantages  for  doing  so,  which  we  briefly  explain  as  follows. 

In  Chapter  1,  we  used  the  following  example  demonstrating  how  to  refine  a  polymorphic 
datatype  into  a  polymorphic  dependent  type. 

datatype  ’a  list  =  nil  |  cons  of  ’a  *  ’  a  list 

typeref  ’a  list  of  nat  (*  indexing  datatype  ’a  list  with  nat  *) 
with  nil  <|  ’a  list(0) 

I  cons  <|  {n:nat]-  ’a  *  ’a  list(n)  ->  'a  list(n+l) 

After  this  declaration,  cons  is  of  type 


Va.nn  :  nat. a  *  ( a)list{n )  — >  ( a)list{n  +  1). 
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Suppose  that  we  have  already  refined  the  type  int,  assigning  the  types  int(O)  and  int(l)  to  0  and 
1,  respectively.  Now  let  us  see  how  to  elaborate  the  expression  cons(( 0,  cons ((1,  nil})}) .  Intuitively, 
we  should  instantiate  the  type  of  the  first  cons  to 

int(0)  *  (int(0 ))list(n)  — ►  (int(0 ))list(n  +  1), 

and  then  check  cons((l,nil})  against  (int(0 ))list{n  +  1).  This  leads  to  the  instantiation  of  the 
type  of  the  second  cons  to 

int(0)  *  (int(0 ))list(n)  — ■>  (int(0))list(n  +  1), 

and  we  then  check  1  against  int(0).  This  results  in  a  type  error  since  1  cannot  be  of  type  int(0). 
In  contrast,  there  exists  no  problem  elaborating  cons(0,  consul,  nil))  into  an  expression  of  type 
(int )list  in  MLq.  This  would  destroy  the  precious  compatibility  property  we  expect,  that  is,  a 
valid  ML  program  written  in  an  external  language  for  ML  can  always  be  treated  as  a  valid  DML(C) 
program.  Fortunately,  the  reader  can  readily  verify  that  the  elaboration  of  cons (0,  consul,  nil)) 
would  have  succeeded  if  we  had  started  checking  it  against  the  type  £a  :  int.  int  (a).  This  ex¬ 
ample  shows  that  it  is  highly  questionable  to  directly  combine  the  dependent  type-checking  with 
polymorphic  type-checking. 

There  is  yet  another  disadvantage.  One  main  objective  of  designing  a  dependent  type  system 
is  to  enable  the  programmer  to  capture  more  program  errors  at  compile  time.  Therefore,  it  is 
crucial  that  adequately  informative  type  error  message  can  be  issued  once  type-checking  fails. 
This,  however,  would  be  greatly  complicated  if  errors  resulted  from  both  dependent  type-checking 
and  polymorphic  type-checking  are  mingled  together,  especially  given  that  it  is  already  difficult 
enough  to  report  only  errors  from  polymorphic  type-checking. 

These  practical  issues  prompt  us  to  adopt  a  two-phase  elaboration  for  MLg'n,S(C'). 

Phase  One 

Theorem  6.2.6  states  that  if  e  is  well-typed  in  MLq’II’S(C')  then  its  index  erasure  ||e||  is  well- typed  in 
MLg.  Therefore,  given  a  program  e  in  DML(C),  if  e  can  be  successfully  elaborated  in  MLQ,n’S((7), 
then  its  index  erasure  ||e||  can  be  elaborated  in  MLq.  We  use  the  W-algorithm  for  polymorphic 
type-checking  in  ML  (Milner  1978)  to  check  whether  ||e||  is  well-typed  in  MLq.  This  is  a  crucial 
step  towards  guaranteeing  full  compatibility  of  MLQ,n’S((7)  with  MLq  in  the  sense  that  a  program 
written  in  an  external  language  for  MLq  should  always  be  accepted  by  MLQ,n,E(C')  if  it  is  by 
MLq.  For  the  parts  of  a  program  which  use  dependent  types,  we  expect  this  phase  of  elaboration 
to  be  highly  efficient  since  there  are  abundant  programmer-supplied  type  annotations  available. 
In  practice,  this  leads  to  accurate  type  error  message  reports  because  type-checking  is  essentially 
performed  in  a  top-down  fashion. 

Phase  Two 

After  the  first  phase  of  elaboration,  we  perform  the  following. 

•  If  a  declared  function  is  not  annotated,  we  annotate  it  with  the  ML-type  inferred  for  this 
function  from  phase  one. 
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(cc,  a' ,  pos) 

a  is  not  a' 
(a,  a' ,  neg) 


(a,  77,  pos)  (a,  T2,  pos) 
(a,  Tl  *  T2,  pos) 

(a,  ri,  neg)  (a,  r2,neg) 
(a,n  *  t-2,  neg) 


(a,  ri,  neg)  (a,  r2,pos) 
(a,n  —  r2,  pos) 

(a,  ti,  pos)  (a,  r2,  neg) 
(a,ri  — *■  r2,  neg) 


(a,n,s(l))  •••  (a 

)  Tfin  «M) 

(a,  (ri, . .  ■  ,rn)5,pos) 


(a,  n,s(l))  •••  (a,Tm,s(m)) 

(a,(Ti,...,Tn)S,  neg) 


Figure  6.7:  The  inference  rules  for  datatype  constructor  status 


•  For  a  let-expression  let  x  =  e\  in  e2  end,  if  the  inferred  type  scheme  of  x  is  of  form  Va.r, 
we  replace  every  free  occurrence  of  x  in  e2  with  x(r)  for  some  appropriate  r  inferred  from 
the  first  phase  of  elaboration.  Notice  that  these  r  are  ML-types.  If  the  programmer  would 
like  to  instantiate  a  with  some  dependent  types,  this  must  be  written  in  the  program.  For 
instance,  the  array  subscript  function  sub  is  of  the  following  type; 

\/a.(a)array  *  int  — >  a 

if  we  need  a  subscript  function  which  only  acts  on  an  array  of  natural  numbers  in  a  block 
of  code,  we  can  declare  let  subNat  =  sub(Ei  :  nat. int (i))  in  . . .  end;  this  assures  that  the 
type  variable  a  in  the  type  of  sub  is  instantiated  with  the  dependent  type  Si  :  nat. int (i), 
which  is  the  type  of  natural  numbers. 

•  If  a  datatype  constructor  5  is  refined  with  index  objects  from  sort  7,  then  we  replace  all 
occurrences  of  (77, . . . ,  rn)5  with  Sa  :  7.(77, . . . ,  Tn)S(a).  This  process  is  then  performed 
recursively  on  r*  for  i  =  1, . . . ,  n. 

After  the  above  processing  is  done,  we  can  readily  elaborate  the  program  in  the  way  described 
in  Section  5.2.  This  concludes  the  informal  description  of  a  two-phase  elaboration  for  MLQ,n’S((7). 

6.2.4  Coercion 

Coercion  between  polymorphic  datatypes  needs  some  special  care.  An  informal  view  is  given  as 
follows.  Assume  that  type  77  can  be  coerced  into  type  r2;  if  a  occurs  positively  in  (a) 5,  then 
(ti)(5  should  be  able  to  coerce  into  (t2)<5;  if  a  occurs  negatively  in  (a)5,  then  (t2)(5  should  be  able 
to  coerce  into  (t\)5.  In  order  to  handle  more  general  cases,  we  introduce  the  notion  of  status  as 
follows. 

Let  6  be  a  datatype  constructor  declared  in  ML  and  Cj  are  constructors  of  type  Vou  . . .  \/am.Ti  —> 
(07, . . . ,  am)6  associated  with  5  for  i  =  1, ...  ,n.  A  status  s  for  5  is  a  function  with  domain 
dom(s)  =  {1, . . . ,  m}  and  range  {pos,  neg}.  We  use  s  for  the  dual  status  of  s,  that  is  s(k )  =  neg 
if  and  only  if  s(k )  =  pos  for  k  =  1, . . . ,  m. 

We  say  that  5  has  status  s  if  for  every  k  6  dom(s),  (a*,,  Ti,  s(k ))  can  be  derived  for  i  =  1,» ...  ,.n 
with  the  rules  in  Figure  6.7. 
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This  can  be  readily  extended  to  mutually  recursively  declared  datatype  constructors  in  ML. 

Assume  that  a  datatype  constructor  S  is  of  status  s.  We  say  that  (ti,  . . . ,  Tm)S(i)  can  be  coerced 
into  (t[,  . . . ,  T'm)8{i)  if  t\,  coerces  into  r'k  for  those  k  such  that  s(k)  =  pos  and  r'k  coerces  into 
for  the  rest. 

We  currently  disallow  coercions  between  (n, . . . ,  Tm)8{i)  and  (r{, . . . ,  T'm)5(i)  if  S  cannot  be 
assigned  a  status.  Clearly,  it  is  possible  to  extend  the  range  of  a  status  function  to  containing 
neutral  and  mixed,  which  roughly  mean  “both  positive  and  negative”  and  “neither  positive  nor 
negative”,  respectively.  However,  we  have  yet  to  see  whether  such  an  extension  would  be  of  some 
practical  relevance. 


6.3  Summary 

Polymorphism  is  largely  orthogonal  to  the  development  of  dependent  types.  In  this  chapter,  MLo 
is  extended  to  MLq  with  let-polymorphism,  and  this  sets  up  the  machinery  we  need  for  combining 
dependent  types  with  let-polymorphism.  Then  the  language  MLq’  ’  (C)  is  introduced,  which 
extends  MLq ’S(C)  with  let-polymorphism.  The  relation  between  MLq’1I'S(C')  and  MLq  is  parallel 
to  that  between  ML0  ’^(C)  and  MLo-  However,  some  serious  problems  show  up  when  elaboration 
is  concerned.  This  prompts  us  to  adopt  a  two-phase  elaboration  process,  which  does  the  usual 
ML-type  checking  in  the  first  phase  and  the  dependent  type-checking  in  the  second  phase.  This 
seems  to  be  a  clean  and  practical  solution. 

MLQ,n,^(C')  is  a  pure  call-by-value  functional  programming  language,  that  is,  it  contains  no 
imperative  features.  Therefore,  the  natural  move  is  to  extend  MLg'n’"J(C')  with  some  imperative 
features,  which  consists  the  topic  of  the  next  chapter. 


Chapter  7 


Effects 


We  have  so  far  developed  the  type  theory  of  dependent  types  in  a  pure  functional  programming 
language  MLQ'n,S(C'),  which  lacks  the  imperative  features  of  ML.  In  this  chapter,  we  extend  the 
language  MLQ,n,“"(C')  to  accommodate  exceptions  and  references.  We  will  examine  the  potential 
problems  and  present  the  approaches  to  solving  them.  The  organization  of  the  chapter  is  as  follows. 

We  first  extend  the  language  MLo  with  the  exceptions  and  formulate  the  language  MLo,exc- 
After  proving  the  type  preservation  theorem  for  MLo,exc>  we  extend  it  with  the  references.  This 
yields  the  language  ML0jexc,ref-  Again,  we  prove  the  type  preservation  theorem  for  ML0,exc,ref-  We 
then  exhibit  what  the  problems  are  if  we  extend  MLq’II’S(C')  with  references  and  exceptions.  This 
leads  to  adopting  the  value  restriction  approach  (Wright  1995).  Finally,  we  study  the  relation 
between  ML0,exc,ref  and  MLp^rcf(C'). 

7.1  Exceptions 

The  exception  mechanism  is  an  important  feature  of  ML  which  allows  programs  to  perform  non¬ 
local  “jumps”  in  the  flow  of  control  by  setting  a  handler  during  evaluation  of  an  expression  that 
may  be  invoked  by  raising  an  exception.  Exceptions  are  value-carrying  in  the  sense  that  they 
can  pass  values  to  exception  handlers.  Because  of  the  dynamic  nature  of  exception  handlers,  it  is 
required  that  all  the  exception  values  have  a  single  datatype  Exc,  which  can  then  be  extended  by 
the  programmer.  This  is  called  extensible  datatype.  We  assume  that  Exc  is  a  distinguished  built-in 
base  type,  but  do  not  concern  ourselves  with  how  constructors  in  this  datatype  are  created. 

7.1.1  Static  Semantics 

The  language  MLo  is  extended  to  the  language  MLo,exc  as  follows.  An  answer  is  either  a  value  or 
an  uncaught  exception. 

base  types  (3  ::=  •  •  •  |  Exc 

expressions  e  ::=  •  •  •  |  raise(e)  |  handle  e  with  ms 

answers  ans  ::=  •  •  •  |  raise(u) 

In  addition  to  the  typing  rules  for  MLo,  we  need  the  following  ones  for  handling  the  newly  intro¬ 
duced  language  constructs. 
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Figure  7.1:  The  natural  semantics  for  MLo,exc  (I) 


r  b  e  :  r  T  b  ms  :  Exc  =4>  r 

r  b  (handle  e  with  ms)  :  r 


(ty-handle) 


T  b  e  :  Exc 
T  b  raise(e)  :  r 


(ty-raise) 


7.1.2  Dynamic  Semantics 

We  now  present  the  evaluation  rules  for  MLo,exc  in  Figure  7.1  and  Figure  7.2,  upon  which  the 
natural  semantics  of  MLo,exc  is  established.  Notice  that  a  successful  evaluation  of  an  expression  e 
results  in  either  a  value  or  an  uncaught  exception. 

Theorem  7.1.1  (Type  preservation)  Assume  that  V  b  e  :  r  is  derivable  in  MLo,exc-  If  e  ^->o  ^ns 
for  some  answer  ans,  then  F  b  ans  :  r  is  derivable. 

Proof  The  proof  is  parallel  to  the  proof  of  Theorem  2.2.7,  following  from  a  structural  induction 
on  the  derivation  D  of  e  v.  We  present  a  few  cases. 

e\  c — >o  raise(ui) 

T)  = - 

raise(ei)  c— >o  raise(ui)  The  derivation  of  T  b  raise(ei)  :  r  must  be  of  the  following 
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e\  c— >o  raise(w) 


(ev-app-1) 


ei(e2)  raise(u) 

e\  c— >o  (lam  x  :  r.e)  e2  raise(u) 

- 7 — 7 - • — rr; -  (ev'a] 

ei(e2)  <-^0  raise(u) 

ei  5 — >o  (lam  x  :  r.e)  e2  v2  e[x  i— >  v2]  ^->o  aras 

ei(e2)  ^->o  ans 

ei  raise(r) 

—  -  -  7  —  (ev-let-1) 

(let  x  =  e\  in  e2  end)  raise(u) 

ei  vi  e2[x  ^  Vi]  ans 


(ev-app-2) 


(ev-app-3) 


(let  x  =  e\  in  e2  end)  c— >o  ans 


(ev-let-2) 


(fix  /  :  T.u)  c  >0  u[f  (fix  /  :  T.U 
e  c — raise(u) 


(ev-fix) 


raise(e)  ^->o  raise(u) 


(ev-raise-1) 

(ev-raise-2) 


raise(e)  ^->o  raise  (r) 
e^0raise(u) 

- - — - — - ; — —  (ev-handler-1) 

handle  e  with  ms  raise(u) 

eo  c— >o  raise(uo)  match(vo,p/c)  0  for  some  1  <  k  <  n  ej.[6]  c->o  ans 
handle  eo  with  (jp\  =^>  e\  \  ■  ■  ■  \  pn  =>•  en)  <— >o  ans 

- - — — 7-fo^ -  (ev-handler-3) 

handle  e  with  ms  ^->n  v 


(ev- handler- 2) 


Figure  7.2:  The  natural  semantics  for  MLo,exc  (II) 
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form. 


T  b  ei  :  Exc 
T  b  raise(ei)  :  r 


(ty-raise) 


By  induction  hypothesis,  T  b  raise(ui)  :  Exc  is  derivable.  Hence,  we  have  a  derivation  of 
r  b  v\  :  Exc.  This  leads  to  the  following. 


T  b  v\  :  Exc 
T  b  raise(-ui)  :  r 


(ty-raise) 


eo  c— >o  raise(uo)  match(uo,Pfc)  =>  0  for  some  1  <  k  <  n  [6\  c— >o  ans 

handle  eo  with  {jp\  =$■  e\  \  ■  ■  ■  \  pn  =$■  en)  c— >o  ans  Then  we  have 

a  derivation  of  the  following  form. 

T  b  e0  :  r  T  b  (pi  =>  ei  \  ■  ■  ■  \  pn  en)  :  Exc  r 

— — - — - — - - - — -  (ty-handle) 

I  b  (handle  eo  with  ei  |  •  •  •  |  pn  =$■  en))  :  r 


By  induction  hypothesis,  T  b  raise(uo)  :  r  is  derivable.  This  leads  to  the  following  derivation. 


rbi)0:  Exc 
T  b  raise  (vq)  :  r 


(ty-raise) 


Notice  T  b  pi  =>■  e*  :  Exc  =$■  r  are  derivable  for  1  <  i  <  n.  Hence  pk  |  Exc  >  T7  is  derivable 
for  some  T7  and  T,r7  b  e&  :  r  is  derivable.  By  Lemma  2.2.5,  T  b  0  :  T7  is  derivable.  This 
leads  to  a  derivation  of  T  b  [9\  :  r  by  Lemma  2.2.4.  By  induction  hypothesis,  T  b  ans  :  r 
is  derivable. 


eo  ^o  v 

V  = - ; - 

handle  eo  with  ms  ^->o  v  Then  we  have  a  derivation  of  the  following  form. 


T  b  eo  :  t  T  b  ms  :  Exc  r 

r  b  (handle  eo  with  ms)  :  r 


(ty-handle) 


By  induction  hypothesis,  T  b  ans  :  r  is  derivable.  Hence,  we  are  done. 

All  other  cases  can  be  treated  similarly.  ■ 


7.2  References 

A  unique  aspect  of  ML  is  the  use  of  reference  types  to  segregate  mutable  data  structures  from 
immutable  ones.  Given  a  type  r,  the  reference  type  r  ref  stands  for  the  type  of  reference  cell 
which  can  only  store  a  value  of  type  r. 


7.2.  REFERENCES 


121 


7.2.1  Static  Semantics 

The  language  MLo,exc  is  extended  to  the  language  MLo,exc,ref  as  follows.  An  answer  is  either  a 
value  or  an  uncaught  exception  associated  with  a  piece  of  memory. 


types 

t  : 

:  = 

•  •  •  |  r  ref 

expressions 

e  : 

:  = 

•  •  •  |  letref  M  in  e  end  |  ei  :=  e2  !e 

memory 

M 

:  = 

•  M,  x  :  t  is  x 

programs 

prog 

:  = 

letref  M  in  e  end 

answers 

ans  : 

:  = 

letref  M  in  v  end  letref  M  in  raise(w)  end 

Let  dom(M)  be  defined 

as  follows. 

dom(-)  =  0  dom (M,  x  :  r  is  v)  =  dom (M)  U  {x} 


For  every  x  €  dom(M),  M(x)  is  v  if  x  :  r  is  v  is  declared  in  M.  For  x  €  dom(Af),  we  use 
M[x  :=  x]  for  the  memory  which  replaces  with  x  :  t  is  x  the  declaration  x  :  r  is  x0id  in  M  for  some 
r  and  x0id- 

We  need  the  following  typing  rules  for  handling  the  newly  introduced  language  constructs. 


T7  =  x\  :  T\  ref, . . ,  ,xn  :  Tn  ref  T, T'  b  Vi  :  Ti  (1  <  i  <  n) 


r  h  (xi  :  n  is  Vi, . . . ,  xn  ■  n  is  vn)  :  F' 
ThM-.V  r,r'he:r 
T  h  let  ref  M  in  e  end  :  r 
r  b  ei  :  r  ref  T  h  e2  :  r 


T  h  ei  :=  e2  :  1 

T  h  e  :  r  ref 
T  h!e  :  r 


(ty-letref) 

(ty-assign) 


(ty-deref) 


(ty-memo) 


Note  that  we  use  Ref(e)  as  an  abbreviation  for  let  x  =  e  in  letref  y  :  r  is  x  in  y  end  end. 

Example  7.2.1  Given  a  derivation  V  of  T  \~  e  :  t,  we  can  construct  the  following  derivation  of 
T  b  Ref(e)  :  r  ref. 


T,  x  :  r,  y  :  r  ref  \~  x  :  t 


r,  x  :  r  h  (y  :  r  is  x)  :  (y  :  r  ref)  T,  x  :  r,  y  :  r  ref  b  y  :  r  ref 


T,  x  :  r  b  letref  y  :  r  is  x  in  y  end  :  r  ref 


(ty-letref) 


T  b  Ref(e)  :  r  ref 


(ty-let) 


7.2.2  Dynamic  Semantics 

The  natural  semantics  of  MLo,exc,ref  is  given  in  Figure  7.3  and  Figure  7.4. 
Proposition  7.2.2  If  the  following  is  derivable,  then  dom(Mi)  C  dom(Af2). 

letref  M\  in  e  end  letref  M2  in  v  end 
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letref  M  in  ()  end  "—>0  let  ref  M  in  ()  end  ^  ^ 

(ev-cons-wo) 


letref  M  in  c  end  ^->0  letref  M  in  c  end 

letref  M \  in  e  end  letref  M2  in  raise(u)  end 
letref  M\  in  c(e)  end  ^->0  letref  M2  in  raise(u)  end 

letref  M\  in  e  end  c— >0  letref  M2  in  v  end 
letref  Mi  in  c(e)  end  ^0  letref  M2  in  c(v)  end 

letref  M\  in  ei  end  ^->0  letref  M2  in  raise(u)  end 


letref  M\  in  (ei,e2)  end  ^->0  letref  M2  in  raise(u)  end 

letref  M\  in  ei  end  ^0  letref  M2  in  v\  end 
letref  M2  in  e2  end  ^->0  letref  M3  in  raise(u)  end 

letref  M\  in  (ei,e2)  end  letref  M3  in  raise(u)  end 


(ev-cons-w-1) 
(ev-cons-w-2) 
(ev-prod-1) 


letref  Mi  in  ei  end 
letref  M2  in  e2  end 


>0  letref  M2  in  v\  end 
>0  letref  M3  in  V2  end 


letref  Mi  in  (ei,e2)  end  letref  M3  in  (v\,V2)  end 
letref  Mi  in  e  end  "—>0  letref  M2  in  raise(u)  end 


letref  Mi  in  case  e  of  ms  end  >0  letref  M2  in  raise(u)  end 

letref  Mi  in  eo  end  >0  letref  M2  in  vq  end 

match(t>o,Pfc)  =>•  0  for  some  1  <  k  <  n 
letref  M2  in  ek[0\  end  >0  ans 


(ev-prod-2) 

(ev-prod-3) 
(ev-case-1) 


letref  Mi  in  case  eo  of  (p\  =>•  ei 


Pn 


end 


>0  ans 


letref  M  in  lam  x  :  r.e  end  ^->0  letref  M  in  lam  x  :  r.e  end 
letref  Mi  in  ei  end  =—>0  letref  M2  in  raise(u)  end 


(ev-case-2) 

(ev-lam) 


letref  Mi  in  ei(e2)  end  ^->0  letref  M2  in  raise(u)  end 


(ev-app-1) 


letref  Mi  in  ei  ^->0  letref  M2  in  lam  x  :  r.e  end  end 
letref  M2  in  e2  ^0  letref  M3  in  raise(u)  end  end 

letref  Mi  in  ei(e2)  end  ^0  letref  M3  in  raise(u)  end 


(ev-app-2) 


letref  Mi  in  ei  end  =—>0  letref  M2  in  (lam  x  :  r.e)  end 
letref  M2  in  e2  end  ^->0  letref  M3  in  V2  end 
letref  M3  in  e[i  i->  V2)  end  ^->0  ans 

letref  Mi  in  ei(e2)  end  c— >0  ans 


(ev-app-3) 


Figure  7.3:  The  natural  semantics  for  MLo,exc,ref  (I) 
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letref  M\  in  e\  end  c— >o  letref  M2  in  raise(u)  end 
letref  Mi  in  (let  x  =  e\  in  e2  end)  end  c— >0  letref  M2  in  raise(u)  end 

letref  M\  in  e\  c— >0  vi  end  letref  M2  in  e2[.x  1— ►  t>i]  end  ^->0  ans 
letref  M\  in  (let  x  =  e\  in  e2  end)  end  ^->0  ans 

letref  M  in  fix  /  :  t.u  end  ^->0  letref  M  in  u[f  1— >  (fix  /  :  t.u )]  end 
letref  M\  in  e  end  =—>0  letref  M2  in  raise(u)  end 


(ev-let-1) 


(ev-let-2) 
(ev-fix) 


letref  M\  in  raise(e)  end  ^->0  letref  M2  in  raise(u)  end 


(ev-raise-1) 


letref  M \  in  e  end 
letref  M\  in  raise(e)  end 


letref  M2  in  v  end 


- - - - - - - - -  (ev- raise- 2) 

>0  letref  M2  in  raise(u)  end 


letref  M\  in  e  end  >0  letref  M2  in  raise(u)  end 
letref  M \  in  handle  e  with  ms  end  c— >0  letref  M2  in  raise(u)  end 

letref  M\  in  eo  end  ^->0  letref  M2  in  raise(uo)  end 
match(i;o,Pfc)  =$■  0  for  some  1  <  k  <  n 
letref  M2  in  e^[9\  end  >0  ans 


(ev-handle-1) 


letref  M\  in  handle  eo  with  (pi  =>•  e\  \  ■  ■  ■  \  pn  =$■  en )  end 
letref  Mi  in  e  end  letref  M2  in  v  end 


letref  Mi  in  handle  e  with  ms  end  c- 
letref  Mi,  M2  in  e  end 


>0  letref  M2  in  v  end 

->0  CLTIS 


-  (ev-handle-2) 

0  ans 

(ev-handle-3) 


letref  Mi  in  letref  M2  in  e  end  end 


0  ans 

letref  M2  in  raise(u)  end 


letref  Mi  in  ei  end  ^->0 
letref  Mi  in  ei  :=  e2  end  c— >0  letref  M2  in  raise(u)  end 


(ev-extrusion) 

(ev-assign-1) 


letref  Mi  in  ei  end  ^0  letref  M2  in  x  end 
letref  M2  in  e2  end  ^->0  letref  M3  in  raise(u)  end 

letref  Mi  in  ei  :=  e2  end  c— >0  letref  M3  in  raise(u)  end 


letref  Mi  in  ei  end 
letref  M2  in  e2  end 


>0  letref  M2  in  x  end 
>0  letref  M3  in  v  end 


letref  Mi  in  ei  :=  e2  end  ^0  letref  M3 [x  :=  v\  in  ()  end 
letref  Mi  in  e  end  ^->0  letref  M2  in  raise(u)  end 


(ev-assign-2) 


(ev-assign-3) 


letref  Mi  in  !e  end  ^0  letref  M2  in  raise(u)  end 

letref  Mi  in  e  end  ^->0  letref  M2  in  x  end 
letref  Mi  in  !e  end  t-»o  letref  M2  in  M2  (a:)  end 


(ev-deref-1) 

(ev-deref-2) 


Figure  7.4:  The  natural  semantics  for  MLo,exc,ref  (II) 
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Proof  This  simply  follows  from  the  formulation  of  the  evaluation  rules.  Note  that  (ev-extrusion) 
is  the  only  rule  which  can  expand  the  memory.  ■ 

Theorem  7.2.3  (Type  preservation)  Given  a  program  P  =  letref  M  in  e  end,  if  ■  \~  P  :  t  and 
P  c — >o  ans  are  derivable  in  ML0)eXc,ref;  then  •  b  ans  :  r  is  also  derivable  in  ML0jexc,ref- 


Proof  The  proof  proceeds  by  a  structural  induction  on  the  derivation  T>  of  P  ans.  We 
present  a  few  cases. 

letref  Mi,  AT  in  e  end  >o  ans 

V  = - ; - ; - 

letref  M\  in  letref  M2  in  e  end  end  ans  Then  we  have  the  following  derivation. 


Id  b  M2  :  r2  Ti, T2  b  e  :  t  .  . 

•  b  Mi  :  Ti  Tib  letref  M2  in  e  end  :  r  1  y~  e  ^  j 
•  b  letref  Al\  in  letref  M2  in  e  end  end  :  r  ^  e  re  ) 


Since  •  b  M\  :  Ti  and  Ti  b  M2  :  T2  are  derivable,  •  b  Mi,  M2  :  ri,T2  is  derivable.  This  leads 
to  the  following. 


b  Mi ,  M2  :  T 1 ,  T2  Ti,  T2  b  e  :  r 
•  b  letref  Mi,  M2  in  e  end  :  r 


(ty-letref) 


By  induction  hypothesis,  •  b  ans  :  r  is  derivable. 


letref  Mi  in  ei  end  ^->0  letref  M2  in  x  end 

letref  M2  in  e2  end  ^0  letref  M3  in  v  end 

letref  Mi  in  ei  :=  e2  end  ^->0  letref  M3 [x  :=  v\  in  ()  end  Then  we  have  a  derivation 
of  the  following  form. 


b  Mi  :  Ti 


Ti  b  ei  :  r  ref  Ti  b  e2  :  r 
Ti  b  ei  :=  e2  :  1 


b  letref  Mi  in  ei  :=  e2  end  :  1 


(ty-assign) 
(ty-letref) 


This  leads  to  the  following. 

•bM,  :r,  r,  be,  :  r  ref  letref) 
•  b  letref  Mi  in  ei  end  :  r  ref  '  ’ 


By  induction  hypothesis,  •  b  letref  M2  in  x  end  :  t  ref  is  derivable.  This  implies  that 
•  b  M2  :  r2  is  derivable  for  some  T2  such  that  T2(x)  =  r  ref.  By  Proposition  7.2.2,  Mi  C  M2. 
Hence,  Ti  CT2,  and  we  have  the  following  derivation. 

•  b  M2  :  r2  r2be2:r 

•  b  letref  M2  in  e2  end  l  Y  letrerl 


By  induction  hypothesis,  •  b  letref  M3  in  v  end  :  r  is  derivable.  This  implies  that  we  can 
derive  •  b  M3  :  T3  for  some  T3  and  T2  C  T3.  Therefore,  •  b  AR[x  :=  v\  :  T3  is  also  derivable, 
and  this  yields  the  following. 


b  M3 [x  :=  v]  :  r3  r3  b  0  :  1 

•  b  letref  M3  in  ()  end  :  1 


(ty-letref) 
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letref  AR  in  e  end  letref  AIo  in  x  end 

V  = - - - 


letref  M\  in  !e  end  letref  AR  in  A^(x )  end 
lowing  form. 

Ti  h  e  :  r  ref 
•  h  Mi  :  T1  F7  He  :  r 
•  h  letref  AI\  in  !e  end  :  r 


Then  we  have  a  derivation  of  the  fol- 

(ty-deref) 

(ty-letref) 


This  leads  to  the  following. 

r,  he,  :rref  letref) 
•  h  letref  AI\  in  e\  end  :  r  ref  '  ’ 


By  induction  hypothesis,  •  h  letref  AI2  in  x  end  :  r  ref  is  derivable.  This  implies  •  h  M2  :  T 2 
is  derivable  for  some  T2  such  that  ^(x)  =  r  ref.  This  then  implies  that  T2  h  M2(x)  :  r  is 
derivable.  Therefore,  we  have  the  following. 

■HM2:r2  r.2HM2(x):r 

•  b  letref  M2  in  M2  (a:)  end  :  t 


The  rest  of  the  cases  can  be  handled  in  a  similar  manner.  ■ 

The  next  theorem  generalizes  Theorem  2.1.4. 

Theorem  7.2.4  We  have  letref  M  in  v  end  ^0  letref  M  in  v  end  for  all  memory  A I  and 
values  v  in  ML0,exc,ref- 

Proof  This  simply  follows  from  a  structural  induction  on  v.  m 


7.3  Value  Restriction 


We  first  mention  some  problems  if  we  extend  MLo.eXc,ref  with  dependent  types  and/or  polymor¬ 
phism.  Let  us  take  a  look  at  the  following  evaluation  rules. 


e 

(A a  :  y.e) 


d  v _ 

d  (A a  :  7-u) 


(ev-ilam) 


(lam  x  :  r.e) 
e 

A  a.e 


->d  (lam  x  :  r.e 
>d  v 


A  a.v 


(ev-lam) 
(ev-poly) 


Clearly,  evaluation  can  occur  under  both  A  and  A  but  cannot  under  lam.  This  can  introduce 
a  serious  problem  when  we  extend  the  language  ML^^C)  with  effects  such  as  exceptions  and 
references.  For  instance,  the  following  cases  arise  immediately. 


1.  If  evaluation  is  allowed  under  A,  then  the  following  rule  must  be  adopted  since  an  exception 
may  be  raised  during  the  evaluation  of  e. 


e  > d  raise(u) 

(Aa  :  y.e)  raise(u) 


(ev-ilam-raise) 


However,  v  may  contain  some  free  occurrences  of  a  when  this  rule  is  applied. 
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2.  Similarly,  we  must  adopt  the  following  rule  if  evaluation  is  allowed  under  A. 

letref  M\,Mo  in  A  a  :  y.e  end  ^->o  o,ns  ,  „  . 

- - — — — ; — - - - — — — ; - - - - -  (ev-ilam-extrusion) 

letret  M  i  in  A  a  :  7. letref  M2  m  e  end  end  ^0  ans 

However,  M2  may  contain  some  free  occurrences  of  a  when  this  rule  is  applied. 

3.  If  evaluation  is  allowed  under  A,  then  we  need  the  following  rule  since  an  exception  may  be 
raised  during  the  evaluation  of  e. 


raise(u) 


(ev-poly-raise) 


(A a.e)  ^ d  raise(u) 

The  problem  is  that  v  may  contain  some  free  occurrences  of  a. 

4.  Similarly,  the  following  rule  is  also  needed. 

letref  Mi,  M2  in  Aa.e  end  ^->0  ans 


letref  M\  in  Act. letref  M2  in  e  end  end  c— >0  ans 


(ev-poly-extrusion) 


The  problem  is  that  M2  may  contain  some  free  occurrences  of  a. 


In  all  of  these  cases,  some  bound  variables  become  unbound  after  the  evaluation.  Clearly,  this 
must  be  addressed  if  we  extend  ML0iexc,ref  with  let-polymorphism  as  well  as  dependent  types. 

A  radical  solution  to  all  the  problems  above  is  to  make  sure  that  we  never  evaluate  under  either 
A  or  A.  In  other  words,  we  should  adopt  instead  the  following  rules. 


(A a  :  y.e)  (A a  :  y.e) 


(ev-ilam) 


Aa.e 


A  a. 


(ev-poly) 


This  seems  to  be  a  clean  solution.  Unfortunately,  the  adoption  of  the  above  rules  immediately 
falsifies  Theorem  6.2.7  and  Theorem  6.2.8  for  the  obvious  reason  that  neither  |jAa  :  y.e 1 1  nor 
||Aa.e||  is  a  value  if  ||e||  is  not.  In  order  to  overcome  this  difficulty,  we  require  that  e  be  a  value 
whenever  either  A  a  :  y.e  or  Aa.e  occurs  in  an  expression.  This  can  be  achieved  if  we  require  ||e|| 
to  be  a  value  when  the  following  typing  rules  are  applied. 


4>,  a  :  7;  A;  T  b  e  :  r 
4>;  A;  T  b  (A a  :  y.e)  :  (na  :  y.r) 


(ty-ilam) 


•;  A,  a;  T  b  e  :  a 
•;  A;  T  h  Aa.e  :  Va.a 


(ty-poly-intro) 


This  is  called  value  restriction.  In  other  words,  we  should  formulate  the  above  rules  as  follows. 

(j>,  a  :  7;  A;  T  b  v  :  r 


A;  T  b  (A a  :  y.u)  :  (na  :  y.r) 
•;  A,  a;  T  b  v  :  a 


(ty-ilam) 


•;  A;  T  b  Aa.w  :  Va.cr 


(ty-poly-intro) 


From  now  on,  we  always  assume  that  value  restriction  is  imposed  unless  it  is  stated  otherwise 
explicitly. 
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7.4  Extending  MLo,exc,ref  with  Polymorphism  and  Dependent  Types 

In  this  section,  we  extend  MLo,exc,ref  with  let-polymorphism  and  dependent  types,  leading  to  the 
language  MLg’^’^:ref(Cl).  Therefore,  we  have  finally  designed  a  language  in  which  there  are  features 
such  as  references,  exceptions,  let-polymorphism  and  both  universal  and  existential  dependent 
types.  Since  the  core  of  ML,  that  is  ML  without  module  level  constructs,  is  basically  MLojexc,ref 
with  let-polymorphism,  we  claim  that  we  have  presented  a  practical  approach  to  extending  the 
core  of  ML  with  dependent  types.  We  regard  this  as  the  key  contribution  of  the  thesis. 

The  complete  syntax  of  MLg’^’^ref  (C)  is  given  in  Figure  7.5.  The  typing  rules  for  MLq’  enxLf(^) 

are  those  presented  in  Figure  6.6  plus  those  in  Figure  7.6.  Also  the  natural  semantics  of  ML  Eef(0 
is  given  in  terms  of  the  evaluation  rules  listed  in  Figure  7.3  and  Figure  7.4  plus  those  in  Figure  7.7. 

Lemma  7.4.1  (Substitution)  We  have  the  following. 

1.  If  both  <f>  h  i  :  7  and  (j>,  a  :  7;  A;  F  h  e  :  r  are  derivable,  then  \  A;  T[a  1— ►  i]  h  e[a  1— ►  i]  :  r[a  1— >  i] 
is  also  derivable. 

2.  If  both  Ahr:*  and  (/>;  A,  a;  T  P  e  :  a  are  derivable,  then  f>;  A;  r[a  1— ►  r]  P  e[a  1— ►  r]  :  a[a  1— ► 
r]  is  also  derivable. 

3.  If  both  4>;  A;  F  P  v  :  07  and  <f  \  A;  T,  x  :  07  P  e  :  cr  are  derivable,  then  <f]  A;  F  P  e[x  1 v\  :  a  is 
also  derivable. 


Proof  The  proof  is  standard  and  therefore  omitted  here.  Please  see  the  proof  of  Lemma  4.1.4 
for  some  relevant  details.  ■ 

Theorem  7.4.2  (Type  preservation  for  MLg’^’(7ref(C')/)  If  both  e  ^ d  ans  :  a  and  e  :  a  are 

derivable  in  MLg’(^ref(C'),  then  ans  :  cj  is  also  derivable  MLg’^’(Tref(C'). 


Proof  The  proof  follows  from  a  structural  induction  on  the  derivation  D  of  e  c— ans  and  the 
derivation  of  •  P  e  :  a,  lexicographically  ordered.  We  present  a  few  cases. 


letref  M\  in  e\  end  letref  M2  in  A  a  :  'y.v  end 

V  = - ; - ; - 

letref  M\  in  e\  [i]  end  letref  M2  in  v[a  >  i]  end  Then  we  have  a  derivation  of  the 

following  form  since  ■;  ■  h  letref  M\  in  e\[i]  end  :  a  is  derivable,  where  a  =  r[a  e- ij. 


Ti  h  ei  :  Ila  :  7-T  •  h  i  :  7 

■;  -Ti  h  ei[i\  :  r[a  i] 


(ty-iapp) 


•;  •  h  Mi:  r. 


h  letref  M\  in  e  1  [z]  end  :  r[a 


(ty-letref) 


This  yields  the  following  derivation. 


S  S  Ti  P  ei  :  11a  :  7.T  Mi  :  Ti 

•;  •;  •  P  letref  M\  in  e\  end  :  Ila  :  j.t 


(ty-letref) 
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families 

5  : 

— 

(family  of  refined  datatypes) 

signatures 

S  : 

•S  |  <S,  5  7  — >  * 

|  S,c  :  A ai - Aam.Hai  :  71  . .  .IIan  :  7„.(ai, . . .  ,am)5(i) 

|  5,  c  .  Aai. . . .  Anm.IIai  .  71  •  •  •  Hon  •  7 n*7"  *  (07 , . . . ,  crm)(5(?') 

major  types 

ll 

:= 

a  |  (cti, . . . ,  am)5(i)  \  1  |  (n  *  r2)  |  (n  -»•  r2) 

types 

t  : 

:= 

p  (Ila  :  7 .t)  (Sa  :  7-r) 

type  schemes 

a 

:= 

r  Aa.u 

patterns 

p 

•— 

x  |  c(ai)  . . .  (am)[oi] . . .  [an]  |  c(«i) . . .  (am)[ai] . . .  [an](p) 

1  0  1  ipi,P2) 

matches 

ms 

:= 

(p  =$■  e)  \  (p  =$■  e  \  ms) 

expressions 

e 

*101  (ei>e2) 

|  c(ri)  . . .  (rm)[ii] . . .  [i in ]  |  c(n) . . .  (rm)[n] . . .  [in](e) 

(case  e  of  ms)  \  (lam  x  :  r.e)  ei(e2) 

|  let  x  =  e\  in  e2  end  (fix  /  :  r.u) 

|  raise(e)  handle  e  with  ms 
|  ei  :=  e2  !e 
|  letref  Af  in  e  end 
|  (Aa  :  j.v)  |  e[i] 

|  (z  |  e)  let  (a  |  x)  =  e\  in  e2  end 

Aa.w 

value  forms 

u 

•— 

c(r 1)  . . .  (tto)[z  1]  . . .  [zn]  1  c(ri) . . .  (rm)[zi] . . .  [in](u)  \  {) 

(ui,  112)  lam  x  :  r.e  |  (Aa  :  7 .it)  (z  u) 

values 

V 

•— 

x(ti)  . . .  (rm)  |  c(n) . . .  (rm)[ii] . . .  [zn]  |  c(n) . . .  (rm)[ zi]  . . .  [zn](r) 

()  |  {vi,V2)  |  (lam  x  :  r.e)  |  (A a  :  7.x)  |  (z  |  v)  \  (A a.v) 

memories 

M  : 

:= 

■  M,  x  :  t  is  x 

programs 

prog 

:= 

letref  M  in  e  end 

answers 

ans 

:= 

letref  A I  in  x  end  letref  A I  in  raise(x)  end 

contexts 

T  : 

:= 

•  |  r,  x  :  a 

type  var  ctxts 

A  : 

:= 

■  A,  a 

index  contexts 

0  : 

:= 

■  I  <t>,a  :  7 

substitutions 

e  : 

:= 

[]  9[x  x]  9[a  z]  9[a  ^  r] 

Figure  7.5:  The  syntax  for  MLg^g^C1) 
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Figure  7.6:  Additional  typing  rules  for  MLg’ex’c  ref(C) 


letref  M  in  A  a  :  'y.v  end  letref  M  in  A  a  :  'y.v  end 

letref  M\  in  e  end  letref  M2  in  raise(u)  end 
letref  Ml  in  e[i]  end  letref  M2  in  raise(u)  end 

letref  M\  in  e  end  c— letref  M2  in  A  a  :  'y.v  end 


(ev-ilam) 


(ev-iapp-1) 


letref  Mi  in  e\i]  end  letref  M2  in  v[a  1— ►  i]  end 

letref  Mi  in  e  end  letref  M2  in  raise(v)  end 
letref  Mi  in  (i  \  e)  end  letref  M2  in  raise(u)  end 


(ev-iapp-2) 


( e  v-sig-int  ro- 1 ) 


letref  Mi  in  e  end  letref  M2  in  v  end 

letref  Mi  in  (i  \  e )  end  letref  M2  in  (i  \  v)  end 

letref  Mi  in  ei  end  letref  M2  in  raise(u)  end 


(ev-sig-intro-1) 


letref  Mi  in  let  (a  \  x)  =  e\  in  e2  end  end  ■— letref  M2  in  raise(u)  end 


(ev-sig-elim-1) 


letref  Mi  in  ei  end  letref  M2  in  (i  \  v)  end 

letref  M2  in  e2[a  1— >  i][x  1— >  v\  end  ans 

-  -  (g\ 

letref  Mi  in  let  (a  \  x)  =  ei  in  e2  end  end  letref  M2  in  ans  end 

letref  M  in  A a.v  end  letref  M  in  Aa.v  end  ^6V 


(ev-sig-elim-2) 


Figure  7.7:  Additional  evaluation  rules  for  MLq’^^C') 
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By  induction  hypothesis,  •;  •;  •  b  letref  M2  in  Xa  :  'y.v  end  :  Ila  :  7 .r  is  derivable.  Therefore, 
we  have  a  derivation  of  the  following  form. 


•;  •;  T2  b  Xa  :  'y.v  :  Ila  :  7.7-  Ah  ■  1^2 

•  b  letref  Ah  in  Xa  :  'y.v  end  :  Ila  :  7 .r 


(ty-letref) 


By  inversion,  we  can  assume  that  a  :  7;  •;  T2  b  v  :  r  is  derivable.  Therefore,  by  Lemma  7.4.1  (1), 
•;  •;  T2  b  v[a  e- >  i]  :  r[a  h  i]  is  derivable  since  a  has  no  free  occurrences  in  rY 

This  leads  to  the  following  derivation  of  ■  b  letref  Ah  in  v[a  1— >  i]  end  :  r[a  1— »  i]. 


•;  -;r2  1-  v[a  i\  :  r[a  1 — >•  *]  Ah  :  T2 

•;  •;  •  b  letref  M2  in  v[a  1— >  i]  end  :  r[a  1— >  i] 


(ty-letref) 


letref  Mi  in  ei  end  letref  M2  in  (i  |  v)  end 
letref  Ah  in  e2 [a  v]  end  ans 

letref  Mi  in  let  (a  |  x)  =  e\  in  e2  end  end  letref  A'h  in  ans  end  Then  we  have 
a  derivation  of  the  following  form. 


Ti  b  ei  :  Sa  :  7 .r  a  :  7;-;Ti,i  :  r  b  e2  :  ff 
• ;  • ;  Ti  b  let  (a  |  x)  =  ei  in  e2  end  :  o 


(ty-sig-elim) 


b  Mi  :  T 1 


b  letref  M \  in  let  (a  |  x)  =  e\  in  e2  end  :  a  end 


(ty-letref) 


This  yields  the  following  derivation. 


•; -;Ti  b  ei  :  Sa  :  j.t  AR  :  Ti 

•  b  letref  Mi  in  ei  end  :  Sa  :  7 .r 


(ty-letref) 


By  induction  hypothesis,  •  b  letref  Ah  in  (i  \  v)  end  :  Sa  :  7 .r  is  derivable.  Therefore, 
we  have  a  derivation  of  the  following  form. 


T2  b  u  :  r[a  1— >  i]  0  b  i  :  7 
•;  •;  r2  b  (i  |  u)  :  Sa  :  7 .r 


(ty-sig-intro) 


•  b  m2  :  r2 


•  b  letref  M2  in  (i  \  v)  end  :  Sa  :  7 .r 


(ty-letref) 


Note  that  •;  •;  Ti  b  e2[a  i][x  v]  :  cr  is  also  derivable  by  Lemma  7.4.1.  This  leads  to  the 
following. 


•;  -;r2  b  e2[a  i][x  ^  v)  :  a  •  b  M2  :  T2 
•  b  letref  A'h  in  e2[a  1 — ^  z] [cc  1 — >•  v\  end  :  a 


(ty-letref) 


By  induction  hypothesis,  ans  is  of  type  a. 


All  other  cases  can  be  dealt  with  in  a  similar  manner.  ■ 

Given  MLg’^’^ref(C'),  it  is  straightforward  to  form  the  language  MLgexC4.ef,  which  extends 
MLo,exc,ref  with  let-polymorphism.  Note  that  value  restriction  is  also  imposed  to  guarantee  the 
soundness  of  the  type  system  of  MLgexcref.  We  leave  the  details  for  the  interested  reader. 
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We  now  extend  the  definition  of  the  index  erasure  function  as  follows. 


raise(e)  || 

handle  e  with  ms 
M,  x  is  u|| 
letref  M  in  e  end 


raise(||e||) 

handle  ||e||  with  ||ms|| 
||M||,x  is  ||u|| 
letref  ||M||  in  ||e||  end 


Theorem  7.4.3  Suppose  that  •;  •;  •  P  e  :  a  is  derivable  in  MLg  excref (^) '  Jf  e  ^ d  ans  is  also 
derivable  in  MLg’^’(Tref(C'),  then  ||e||  llansll  derivable  in  MLgexcref. 


Proof  This  follows  from  a  structural  induction  on  the  derivation  V  of  e  ^d  ans  and  the  derivation 
of  •;  •;  •  b  e  :  a,  lexicographically  ordered.  We  present  a  few  cases. 

V  = - ; - ; - 

letref  M  in  A  a  :  j.v  end  ^d  letref  M  in  A  a  :  j.v  end  ]  Notice  that  we  have  the  fol¬ 
lowing. 

||letref  M  in  A  a  :  'y.v  end||  =  letref  \\M\\  in  ||u||  end. 

By  Proposition  7.2.4,  we  have 

letref  ||M||  in  ||u||  end  c— >o  letref  \\M\\  in  ||u||  end 

since  ||u||  is  obviously  a  value. 

V  = - ; - ; - 

letref  M  in  Aa.v  end  c— ► d  letref  M  in  Aa.v  end  Notice  that  we  have  the  following. 

jjletref  M  in  Aa.v  end||  =  letref  ||M||  in  ||u||  end. 

By  Proposition  7.2.4,  we  have 

letref  \\M\\  in  ||u||  end  letref  \\M\\  in  ||u||  end 

since  ||u||  is  obviously  a  value. 

All  other  cases  can  be  treated  as  done  in  the  proof  of  Theorem  6.1.3.  ■ 

Suppose  that  we  formulate  a  reduction  semantics  for  MLg’^’^ref(C').  Then  a  legitimate  question  to 
ask  is  whether  an  expression  of  form  Aa.e  (A a  :  j.e)  for  some  non-value  e  can  be  generated  during 
the  reduction  of  a  program  p  in  which  there  are  no  such  expressions.  The  answer  is  negative  since 
MLg’^’^ref(C')  is  a  call- by- value  language.  Therefore,  not  surprisingly,  a  type  preservation  theorem 

for  MLg’^’(^1.ef(C')  can  also  be  formulated  and  proven  using  reduction  semantics.  Usually,  such  a 
theorem  is  called  subject  reduction  theorem.  We  leave  the  details  for  the  interested  reader. 

Theorem  7.4.4  Suppose  that  P  e  :  a  is  derivable  in  MLg  5cSref(C')-  Jf  INI  ans0  is 
derivable  in  MLgexc  ref,  then  e  d  cms  is  also  derivable  in  MLg’^’^ref(C')  for  some  ans  such  that 
||ans||  =  anso. 
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Proof  The  proof  proceeds  by  a  structural  induction  on  the  derivation  Vq  of  ||e||  =—>0  anso  and 
the  derivation  T>  of  •;  •;  •  b  e  :  a,  lexicographically  ordered.  We  present  one  case. 

•;  •;  •  b  eo  :  r  •  b  ms  :  Exc  =$■  r 

V  = - ; - 

•  b  (handle  eo  with  ms)  :  r  Then  we  have 


||e||  =  ||handle  eo  with  ms ||  =  handle  ||eo||  with  ||ms||. 

The  derivation  Vo  of  ||e||  >o  anso  must  be  one  of  the  following  forms. 

letref  •  in  II eo  II  end  ^o  letref  M°  in  raise(u°)  end 

Vo  = - 

letref  •  in  handle  ||eo||  with  ||ms||  end  ^o  letref  M°  in  raise(u°)  end  By  in¬ 
duction  hypothesis,  letref  •  in  eo  end  ^d  letref  M  in  raise(u)  end  is  derivable  for 
some  M  and  v  such  that  ||M||  =  M°  and  ||u|j  =  v°.  This  leads  to  the  following. 


letref  •  in  eo  end  letref  M  in  raise(u)  end 
letref  •  in  handle  eo  with  ms  end  ^>d  letref  M  in  raise(u)  end 


(ev-handle-1) 


Hence,  we  are  done. 

letref  •  in  ||eo||  end  ^o  letref  M°  in  raise(u°)  end 
match(u°,  ||pfc||)  =>■  #o  for  some  1  <  k  <  n 
letref  M°  in  ||  e^  ||  [6*o]  end  anso 

letref  •  in  handle  ||eo||  with  (p\  =$■  e\  \  ■  ■  ■  \  pn .  =>■  en)  end  ojisq  By  induc¬ 
tion  hypothesis,  letref  •  in  eo  end  ^d  letref  M  in  raise(w)  end  is  derivable  for  some 
M  and  v  such  that  \\M\\  =  M°  and  ||u||  =  u°.  By  Theorem  7.4.2,  •;  •;  •  b  v  :  cr  is  derivable. 
By  Proposition  6.2.1,  match(u,pfc)  ==>  9  is  derivable  for  some  9  such  that  ||0||  =  9o,  and 
therefore,  ||efc[0]||  =  ||efc||[#o]-  By  induction  hypothesis,  letref  M  in  ek[9\  end  c— ans 
for  some  ans  such  that  ||ans||  =  anso-  This  leads  to  the  following. 


letref  ■  in  eo  end  c— > d  letref  M  in  raise(u)  end 

match(u,pfc)  ==>  9  for  some  1  <  k  <  n 
letref  M  in  ek[9\  end  c— >d  ans 

letref  •  in  handle  eo  with  (jp\  =>  e\  |  •  •  •  |  pn  =>  en)  end  >d  ans 


(ev-handle-2) 


This  concludes  the  subcase. 

letref  •  in  ||eo||  end  ^->o  letref  in  v°  end 

letref  ■  in  handle  ||eo||  with  ||ms||  end  ^o  letref  M°  in  end  By  induction 
hypothesis,  letref  •  in  eo  end  letref  M  in  v  end  is  derivable  for  some  M  and  v 
such  that  \\M\\  =  M°  and  ||u||  =  v°.  This  leads  to  the  following. 


letref  •  in  eo  end  ^->o  letref  M  in  v  end 
letref  ■  in  handle  eo  with  ms  end  c— >o  letref  M  in  v  end 


(ev-handle-3) 


Hence,  we  are  done. 
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All  other  cases  can  be  treated  similarly. 


We  have  thus  extended  the  entire  core  of  ML  with  dependent  types.  Given  the  comprehensive 
features  of  the  core  of  ML,  this  really  is  a  solid  justification  on  the  feasibility  of  our  approach  to 
making  dependent  types  available  in  practical  programming.  Naturally,  the  next  move  is  to  enrich 
the  module  system  of  ML  with  dependent  types,  which  we  regard  as  a  primary  future  research 
topic. 

7.5  Elaboration 

We  briefly  explain  how  elaboration  for  MLq’^"  f(C)  is  performed.  We  concentrate  on  the  newly 

n  s 

introduced  language  constructs  rather  than  present  all  the  elaboration  rules  as  done  for  ML0  ’“'(C), 
which  is  simply  too  overwhelming  in  this  case.  We  also  ignore  type  variables  since  polymorphism 
is  large  orthogonal  to  dependent  types  as  explained  in  Chapter  6. 

The  elaboration  rules  for  references  and  exceptions  are  listed  in  Figure  7.8.  We  omit  the 
formulation  of  the  corresponding  constraint  generation  rules.  Also  it  is  a  routine  to  formulate  and 
prove  a  similar  version  of  Theorem  5.2.6  for  MLq’^’^.^C'),  which  justifies  the  correctness  of  these 
elaboration  rules.  We  leave  out  details  since  we  have  adequately  presented  in  the  previous  chapters 
the  techniques  needed  for  fulfilling  such  a  task. 

7.6  Summary 

In  this  chapter  we  studied  the  interactions  between  dependent  types  and  effects  such  as  references 
and  exceptions.  Like  polymorphism,  dependent  types  cannot  be  combined  with  effects  directly 
for  the  type  system  would  be  unsound  otherwise.  A  clean  solution  to  this  problem  is  to  adopt  a 
value  restriction  on  formulating  expressions  of  dependent  function  types.  The  development  seems 
to  be  straightforward  after  this  adoption.  However,  this  problem  also  exhibits  another  inadequate 
aspect  of  the  type  system  of  ML  for  it  cannot  distinguish  the  functions  which  have  effects  from 
those  which  do  not.  It  will  be  interesting  to  see  how  this  can  be  remedied  in  future  research. 

The  type  system  of  MLg’^’(^1.ef(C'),  which  includes  let-polymorphism,  effects  and  dependent 
types,  has  reached  the  stage  where  it  is  difficult  to  manipulate  without  mechanical  assistance.  For 
instance,  we  presented  only  one  case  in  the  proof  of  Theorem  7.4.4,  and  left  out  dozens.  Since 
almost  all  the  proofs  in  this  thesis  are  based  on  some  sort  of  structural  induction,  it  seems  highly 
relevant  to  investigate  whether  an  interactive  theorem  prover  with  certain  automation  features  can 
accomplish  the  task  of  fulfilling  the  cases  that  we  omitted.  The  interested  reader  can  find  some 
related  research  in  (Schiirmann  and  Pfenning  1998). 
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hr:*  <j)]T  \~  e  l  Exc  =J>  e* 

;T  h  raise(e)  j  r  =>  raise(e*) 

^rhejr^e*  (/>;  T  h  ms  j  (Exc  =4>  r)  ?ns 


0;  r  h  (handle  e  with  ms)  |  t  =>•  (handle  e*  with  ms 

</>; T  h  e  |  t  =>-  e*  ^Th  ms  j  (Exc  =4>  r)  =>-  ms* 
i>;T  h  (handle  e  with  ms)  |  r  =>•  (handle  e*  with  ms*) 


(elab-raise) 

(elab- handle-up) 


(elab-handle-down) 


;T  b  e  T  T 


(j);F  h  Ref(e)  |  t  ref  =>  Ref(e* 

_ 4>;  T  I-  e  |  r  =>•  e* _ 

;  r  |-  Ref(e)  j  r  ref  Ref(e*) 


(elab-ref-up) 


(elab-ref-down) 


6;  T  h  e  |  t  ref  =>  e* 
(f>;  T  He  |  t  =>\e* 


(elab-deref-up) 


;  T  h  e  |  r  ref  =>  e* 


<j>;  T  He  |  r  =He: 

</>;  T  h  e\  |  t  ref  =>  e\  (/>;  T  h  e2  |  r  =>  e| 

</>;  T  h  ei  :=  e2  T  1  ei  :=  e2 

6;  T  h  ei  |  r  ref  =>  e\  <fi;  T  h  e2  j  r  =>•  eJj 


;  T  h  ei  :=  e2  |  1  e*  :=  e\ 


(elab-deref-down) 

(elab- assign-up) 
(elab-assign-down) 


Figure  7.8:  Some  elaboration  rules  for  references  and  exceptions 


Chapter  8 

Implementation 


We  have  finished  a  prototype  implementation  of  dependent  type  inference  in  Standard  ML  of  New 
Jersey,  version  110.  The  implementation  corresponds  closely  to  the  theory  developed  in  the  previous 
chapters.  All  the  examples  presented  in  Appendix  A  have  been  verified  in  this  implementation. 

In  this  chapter,  we  account  for  some  decisions  we  made  during  this  implementation.  However, 
this  chapter  is  not  meant  to  be  complete  instructions  for  using  the  prototype  implementation. 
The  syntax  for  the  expressions  recognized  by  the  implementation  is  similar  to  that  of  the  external 
language  DML(C')  for  MLg’(^ref(C'),  including  let-polymorphism,  references,  exceptions,  universal 
and  existential  dependent  types.  The  record  types,  which  can  be  regarded  as  a  sugared  version  of 
product  types,  are  not  available  at  this  moment.  Most  of  the  features  can  be  found  in  the  examples 
presented  in  Appendix  A. 

The  grammar  for  a  sugared  version  of  DML(C')  closely  resembles  that  of  Standard  ML  in  the 
sense  that  a  DML(C)  program  becomes  an  SML  one  if  all  syntax  related  to  type  index  objects  is 
erased.  Therefore,  we  will  only  briefly  go  over  the  syntax  related  to  dependent  types.  Also  note 
that  the  explanation  will  be  given  in  an  informal  way  since  most  of  the  syntax  for  DML(C)  is  likely 
to  change  in  future  implementations. 

Lastly,  we  will  move  on  to  mention  some  issues  on  implementing  the  elaboration  algorithm 
presented  in  Chapter  5. 


8.1  Refinement  of  Built-in  Types 

We  have  refined  the  built-in  types  int,  bool  and  'a  array  in  ML  below. 

•  int  is  refined  into  infinitely  many  singleton  types  int(n),  where  n  are  of  integer  values.  In 
other  words,  if  a  value  v  is  of  type  int(n)  for  some  n,  then  v  is  equal  to  n.  As  a  consequence, 
int  becomes  a  shorthand  for  Hn  :  int.  int  (n). 

•  bool  is  refined  into  two  singleton  types  bool(6),  where  b  is  either  T  or  _L.  true  and  false  are 
assigned  types  bool(T)  and  bool(T)  respectively.  As  a  consequence,  bool  is  a  shorthand  for 
T,b  :  o.bool(T). 

•  'a  arrayis  refined  into  infinitely  many  dependent  types  ’a  array (n)  where  n  stands  for  the 
size  of  the  array. 
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int.TIn 

int.int(m ) 

* 

int(n )  — > 

bool(m  >  n) 

> 

Ilm. 

int.TIn 

int.int(m ) 

* 

int(n)  — > 

bool{m  >  n) 

array 

Aa.IIn  :  nat. a  *  int(n )  — 

■>  ( a)array( 

n) 

length 

Aa.IIn  :  nat.{a)array{n 

- 

int{n ) 

Figure  8.1:  Dependent  types  for  some  built-in  functions 
Also  we  have  assigned  dependent  types  to  some  built-in  functions  on  integers,  booleans  and  arrays. 


8.2  Refinement  of  Datatypes 

During  the  development  of  various  dependent  type  systems  in  previous  chapters,  we  implicitly 
assumed  that  a  declared  (polymorphic)  datatype  constructor  5  :  *  — >•••— *  in  ML  can  be 
refined  into  a  dependent  datatype  constructor  A  :  *  — ^  -  -  -  — ^  ^  *  for  some  index  sort  7,  and 

every  constructor  c  associated  with  5  of  type  Acci.  •  •  •  .A am.r  — >  6  is  then  assigned  a  dependent 
type  of  form 

Aon  . . .  Aam.IIai  :  ry. . . .  II an  :  7n-f  >  (cci , ... ,  crm)5((Zi , . . . ,  an .) , 

where  71  *  •  •  •  *  7n  =  7-  We  now  use  an  example  to  illustrate  how  a  datatype  refinement  declaration 
is  formulated  in  the  implementation. 

Given  the  datatype  constructor  tree  as  follows, 

datatype  ’  a  tree  =  Leaf  |  Branch  of  ’a  *  ’a  tree  *  ’a  tree 

the  following  is  a  datatype  refinement  declaration  for  tree. 

typeref  ’a  tree  of  nat  with 
Leaf  <|  ’a  tree(O) 

I  Branch  < | 

{sl:nat,  sr:nat}  'a  *  Ja  tree(sl)  *  ’a  tree(sr)  ->  ’a  tree(l+sl+sr) 

This  declaration  states  that  the  datatype  constructor  tree  :  *  — >  *  has  been  refined  into  a  dependent 
datatype  constructor  tree  :  *  — >  nat  — ►  *.  Also  the  associated  constructors  Leaf  and  Branch  have 
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been  assigned  the  following  types,  respectively. 

Aa.(a)tree(0 )  and  Act. Ids/  :  nat.Tlsr  :  nat.a  *  (a)tree(sl)  *  (a)tree(sr)  —>  (a)tree(  1  +  si  +  sr) 

Clearly,  the  meaning  of  the  type  index  i  in  ( a)tree(i )  is  the  size  of  the  tree.  If  one  would  like  to 
index  a  tree  with  its  height,  then  the  following  declaration  suffices. 

typeref  ’a  tree  of  nat  with 
Leaf  <|  ’a  tree(O) 

I  Branch  < | 

{hl:nat,  hr:nat}  'a  *  Ja  tree(sl)  *  ’a  tree(sr)  ->  ’a  tree(l+max(hl,  hr)) 

Moreover,  if  one  would  like  to  index  a  tree  with  both  its  size  and  its  height,  then  the  declaration 
can  be  written  as  follows. 

typeref  ’a  tree  of  nat  *  nat  with 
Leaf  <|  ’a.  tree(0,  0) 

I  Branch  < | 

{{si: nat,  sr:nat,  hi: nat,  hr: nat} 

’a  *  ’a  tree(sl,  hi)  *  ’a  tree(sr,  hr)  ->  ’a  tree(l+sl+sr,  l+max(hl,  hr)) 

More  sophisticated  datatype  refinement  declarations  can  be  found  in  the  examples  presented  in 
Appendix  A.  Note  that  a  datatype  can  be  refined  at  most  once  in  the  current  implementation  for 
the  sake  of  simplicity. 


8.3  Type  Annotations 

The  constraint  generation  rules  for  elaboration  presented  in  Chapter  5  require  that  the  programmer 

supply  adequate  type  annotations.  Roughly  speaking,  the  dependent  types  of  declared  function 

should  be  determined  by  the  programmer  rather  than  synthesized  during  elaboration.  The  main 

n  s 

reason  for  this  is  that,  unlike  in  ML,  there  exists  no  notion  of  principal  types  in  ML0  ’  (C) . 

The  type  annotation  for  a  function  can  be  supplied  through  the  use  of  a  where  clause  following 
the  function  declaration.  Suppose  that  the  following  datatype  refinement  has  been  declared. 

datatype  ’a  list  =  nil  |  cons  of  ’a  *  ’a  list 

typeref  ’a  list  of  nat  with 
nil  <|  ’a  list(0) 

I  cons  <|  {n:nat}  'a  *  ’a  list(n)  ->  ’a  *  ’a  list(n+l) 

Then  the  following  function  declaration  contains  a  type  annotation  for  the  declared  function 
reverse. 

fun(  ’  a) 

reverse(nil)  =  nil 

I  reverse (cons (x,  xs))  =  reverse(xs)  @  cons(x,  nil) 
where  reverse  <|  {n:nat}  ’a  list(n)  ->  ’a  list(n) 
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The  type  annotation  states  that  the  reverse  is  a  function  of  type  Iln  :  nat.(a)list(n)  — >  ( a)list(n ). 
The  above  declaration  roughly  corresponds  to  the  following  expression  in  DML(C'). 

Aa.fix  reverse  :  Iln  :  nat.(a)list(n)  —>  ( a)list(n ). 

An. lam  Lease  l  of  nil  nil  \  cons((x,xs))  =$■  reverse(xs)@cons((x,  nil)) 

There  is  another  form  of  type  annotation  shown  in  the  following  example,  which  is  a  slight  variant 
of  the  example  in  Figure  1.1. 

fun(  ’a){n:nat]- 
reverse(l)  = 
let 

fun  rev (nil,  ys)  =  ys 

I  rev(cons(x,  xs) ,  ys)  =  rev(xs,  cons(x,  ys)) 
where  rev  <|  {m:nat]-{n:nat}-  ’a.  list(m)  *  ’a  list(n)  ->  ’a  list(m+n) 
in  rev(l,  nil)  end 

where  reverse  <|  'a  list(n)  ->  ’a  list(n) 

reverse  is  now  defined  in  the  tail-recursive  style.  Notice  that  {n:nat}  follows  fun  (’a)  in  this 
declaration,  which  corresponds  to  the  following  expression  in  DML(C). 

Aa.Xn  :  nat. fix  reverse  :  ( a)list(n )  — »  ( a)list(n ). 

let  rev  =  fix  rev  :  Ilm  :  nat. Tin  :  nat.(a)list(m)  *  ( a)list(n )  — >  ( a)list(m  +  n). 

Am. An. lam  l. 

case  l  of  (nil,  ys)  =$■  ys 

|  (cons((x,  xs)),ys)  =3-  rev((xs,cons((x,ys)))) 

in  rev ({l,  nil ))  end 

Another  kind  of  type  annotation  is  essentially  like  the  type  annotation  in  ML  except  that  <  I 
is  used  instead  of  :  and  a  dependent  type  is  supplied.  For  instance,  the  type  annotation  in  the 
following  code,  extracted  from  the  example  in  Section  A. 5,  captures  the  relation  between  front 
and  srealign. 

f unfsrealign : int} 

aligned(src,  srepos,  endsrc,  dest,  destpos,  srealign,  bytes)  = 
let 

val  front  = 

(case  srealign  of 
0  =>  0 
I  1  =>  3 
I  2  =>  2 

I  3  =>  1)  <|  [i:nat  | 

(srealign  =  0  /\  i  =  0)  \/ 

(srealign  =  1  /\  i  =  3)  \/ 

(srealign  =  2  /\  i  =  2)  \/ 

(srealign  =  3  /\  i  =  1)  ]  int(i) 
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in 

end 

We  list  as  follows  some  less  common  syntax  in  the  implementation  and  its  corresponding  part  in 
MLg’^’^ref(C'),  helping  the  reader  to  understand  examples. 


implementation 

ML^;^ref(C) 

e  <  1  r 

e  :  r 

Pi  A  P-2 

Pi  A  P2 

Pi  V  P-2 

Pi  V  P2 

{«1  •  7l . O'n  •  bn} 

Veil  :  71  •  •  -  Vein  :  7 n- 

{ai  :  71, . . .  ,an  :  7„  P} 

Vai  :  71 . . .  Van  :  {a  :  jn  \  P[an  a]}. 

[®1 . 71,  •  •  •  ,  CLn  .  7n] 

3ai  :  71 . . .  3an  :  7„. 

[ai  :  71, . . .  ,an  :  7n  |  P] 

3ai  :  71 . . .  3an  :  {a  :  7n  |  P[an  a]}. 

8.4  Program  Transformation 

There  is  a  significant  issue  on  whether  a  variant  of  A-normal  transform  should  be  performed  on 
programs  before  they  are  elaborated.  The  advantage  of  doing  the  transform  is  that  a  common  form 
of  expressions  are  then  able  to  be  elaborated  which  would  otherwise  not  be  possible.  However,  the 
transform  also  prevents  us  from  elaborating  a  less  common  form  of  expressions.  This  drawback, 
however,  can  be  largely  remedied  by  define  ei(e2)  as  follows. 


eijgg) 


let  xi  =  e\  in  .xi(e2)  end  if  e2  is  a  value; 

let  x\  =  e\  in  let  x 2  =  e2  in  x\{x2)  end  end  otherwise. 


A  more  serious  disadvantage  of  performing  the  transform  is  that  it  can  significantly  complicate  for 
the  programmer  the  issue  of  understanding  the  error  messages  reported  during  elaboration  since 
he  or  she  may  have  to  understand  how  the  programs  are  transformed. 

The  transform  is  performed  in  the  current  prototype  implementation.  Since  little  attention  is 
paid  to  reporting  error  messages  in  this  implementation,  the  issue  has  yet  to  be  addressed  in  future 
implementations.  We  would  also  like  to  study  the  feasibility  of  allowing  the  programmer  to  guide 
the  transform  with  some  syntax. 


8.5  Indeterminacy  in  Elaboration 

The  constraint  generation  rules  for  coercion  as  presented  in  Figure  5.2  contain  a  certain  amount  of 
indeterminacy.  Since  we  disallow  backtracking  in  elaboration  for  the  sake  of  practicality,  we  have 
imposed  the  following  precedence  on  the  application  of  these  rules,  that  is,  the  rule  with  a  higher 
precedence  is  chosen  over  the  other  if  both  of  them  are  applicable. 


(coerce-pi-r)  >  (coerce-sig-1)  >  (coerce-pi-1)  >  (coerce-sig-r) 
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Given  (f>\~  t  :  *  derivable,  the  above  strategy  guarantees  that  4>  H']  coerc e(r,  r)  $  is  derivable 
for  some  $  such  that  (j)  |=  $  is  derivable.  However,  the  programmer  must  use  language  constructs  to 
guide  coercion,  sometimes.  For  instance,  given  a  function  /  of  type  77  =  na  :  7. (5(a)  — ►  5(z),  one  can 
define  g  as  lam  re. let  y  =  x  in  f(y)  end  and  assign  it  the  type  77  =  (Ea  :  7.5(a))  — >  (Sa  :  7.5(a)). 
This  type-checks.  Notice  that  it  could  not  have  succeeded  with  the  precedence  above  if  we  had 
coerced  77  into  t-2  directly. 

Similarly,  the  rule  (constr-pi-intro-1)  is  always  chosen  over  (constr-pi-intro-2)  if  both  are 
applicable.  There  is  yet  another  issue.  Suppose  that  we  have  synthesized  the  type  r  of  an  expression 
e  for  r  =  na  :  7.77 .  Clearly,  the  rule  (constr-pi-elim)  is  applicable  now.  Should  we  apply  the 
rule?  In  the  implementation,  we  apply  the  rule  only  if  e  occurs  as  a  subexpression  of  e(e')  or 
case  e  of  ms. 

This  pretty  much  summarizes  how  indeterminacy  in  elaboration  is  dealt  with  in  the  prototype 
implementation. 


8.6  Summary 

We  have  finished  a  prototype  implementation  in  which  there  are  features  such  as  datatype  decla¬ 
rations,  higher-order  functions,  let-polymorphism,  references,  exceptions,  and  both  universal  and 
existential  dependent  types.  The  only  missing  main  feature  in  the  core  of  ML  is  records ,  which  can 
be  regarded  as  a  variant  of  product.  The  implementation  sticks  tightly  to  the  theory  developed  in 
the  previous  chapters. 

In  the  implementation  of  the  elaboration  described  in  Section  5.2,  we  have  to  cope  with  some 
indeterminacy  in  the  constraint  generation  rules  for  elaboration  and  coercion.  The  important 
decision  we  adopt  is  that  we  disallow  the  use  of  backtracking  in  type-checking.  The  main  reason 
for  this  decision  is  that  backtracking  can  not  only  significantly  slow  down  type-checking  but  also 
make  it  almost  impossible  to  report  type-error  messages  in  an  acceptable  manner.  We  are  now 
ready  to  harvest  the  fruit  of  our  hard  labor,  mentioning  some  interesting  applications  of  dependent 
types  in  the  next  chapter. 


Chapter  9 

Applications 


In  this  chapter,  we  present  some  concrete  examples  to  demonstrate  various  applications  of  depen¬ 
dent  types  in  practical  programming.  All  the  examples  in  Section  9.1  and  Section  9.2  have  been 
verified  in  the  prototype  implementation.  The  ones  in  Section  9.3  are  for  the  future  research. 

9.1  Program  Error  Detection 

It  was  our  original  motivation  to  use  dependent  types  to  capture  more  programming  errors  at 
compile-time.  We  report  some  rather  common  errors  which  can  be  captured  with  the  dependent 
type  system  developed  in  this  thesis.  Notice  that  all  these  errors  slip  through  the  type  system  of 
ML. 

We  have  found  that  it  is  significantly  beneficial  for  the  programmer  to  be  able  to  verify  certain 
properties  about  the  lengths  of  lists  in  programs.  For  instance,  the  following  is  an  implementation 
of  the  quicksort  algorithm  on  lists. 

fun( ’ a) 

quicksort  cmp  []  =  [] 

I  quicksort  cmp  (x: :xs)  =  par  cmp  (x,  [] ,  [] ,  xs) 
where  quicksort  <| 

-Cn:nat}-  (’a  *  ’a  ->  bool)  ->  ’a  list(n)  ->  ’a  list(n) 
and ( ’ a) 

par  cmp  (x,  left,  right,  xs)  = 
case  xs  of 

[]  =>  (quicksort  cmp  left)  @  (x  : :  (quicksort  cmp  right)) 

I  y: :ys  => 

if  cmp(y,  x)  then  par  cmp  (x,  y::left,  right,  ys) 
else  par  cmp  (x,  left,  y: :right,  ys) 
where  par  <|  {p:nat,q:nat,r :nat}  (’a  *  ’a  ->  bool)  -> 

’a  *  ’a  list(p)  *  ’a  list(q)  *  ’a  list(r)  ->  Ja  list (p+q+r+1) 

If  the  line  below  case  is  replaced  with  the  following, 

[]  =>  (quicksort  cmp  left)  @  (quicksort  cmp  right) 
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datatype  ’a  diet  = 

Empty  (*  considered  black  *) 

I  Black  of  ’a  entry  *  ’a  diet  *  ’a  diet 
I  Red  of  ’a  entry  *  ’a  diet  *  ’a  diet 

typeref  ’a  diet  of  bool  *  nat  with 
Empty  <|  ’a  diet (true,  0) 

I  Black  < | 

{cl:bool,  cr:bool,  bh:nat} 

’a  entry  *  ’a  diet (cl,  bh)  *  ’a  dict(cr,  bh)  ->  ’a  diet (true,  bh+1) 

I  Red  <| 

{bh:nat} 

’a  entry  *  ’a  diet (true,  bh)  *  'a  diet (true,  bh)  ->  ’  a  diet (false,  bh) 


Figure  9.1:  The  red/black  tree  data  structure 


that  is,  the  programmer  forgot  to  include  x  in  the  result  returned  by  the  function  par,  then  the 
function  could  not  be  of  the  following  type. 

{p:nat,q:nat,r:nat}  (’a  *  ’a  ->  bool)  -> 

’a  *  ’a  list(p)  *  ’a  list(q)  *  ’a  list(r)  ->  ’a  list (p+q+r+1) 

As  matter  of  a  fact,  the  function  par  is  of  the  following  type  after  the  replacement. 

{p:nat,q:nat,r:nat}  (’a  *  ’a  ->  bool)  -> 

’a  *  ’a  list(p)  *  ’a  list(q)  *  ’a  list(r)  ->  ’a  list(0) 

Therefore,  the  above  error  is  caught  at  compile-time  when  type-checking  is  performed. 

We  now  present  a  more  realistic  example.  A  red/black  tree  is  a  balanced  binary  tree  which 
satisfies  the  following  conditions. 

1.  All  leaves  are  marked  black  and  all  other  nodes  are  marked  either  red  or  black. 

2.  Given  a  node  in  the  tree,  there  are  the  same  number  of  black  nodes  on  every  path  connecting 
the  node  to  a  leaf.  This  number  is  called  the  black  height  of  the  node. 

3.  The  two  sons  of  every  red  node  are  black. 

In  Figure  9.1,  we  define  a  polymorphic  datatype  'a  diet,  which  is  essentially  a  binary  tree 
with  colored  nodes.  We  then  refine  the  datatype  with  type  index  objects  (c,  bh)  drawn  from  the 

sort  bool  *  nat,  where  c  and  bh  are  the  color  and  the  black  height  of  the  root  of  the  binary  tree. 

The  node  is  black  if  and  only  if  c  is  true.  Therefore,  the  properties  of  a  red/black  tree  is  naturally 
captured  with  this  datatype  refinement.  This  enables  the  programmer  to  catch  program  errors 
which  lead  to  violations  of  these  properties  when  implementing  an  insertion  or  deletion  operation 
on  red/black  trees.  We  have  indeed  encountered  errors  caught  in  this  way  in  practice. 

Notice  that  this  refinement  is  different  from  the  one  declared  in  Section  A. 2,  which  is  more 
suited  for  the  implementation  presented  there. 
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9.2  Array  Bound  Check  Elimination 

Array  bounds  checking  refers  to  determining  whether  the  value  of  an  expression  is  within  the 
bounds  of  an  array  when  it  is  used  to  index  the  array.  Bounds  violations,  such  as  those  notorious 
“off-by-one”  errors,  are  among  the  most  common  programming  errors. 

•  Pascal,  Ada,  SML,  Java  are  among  the  programming  languages  which  require  that  all  bounds 
violations  be  captured. 

•  C,  C++  are  not. 

However,  run-time  array  bounds  checking  can  be  very  expensive.  For  instance,  it  is  observed 
that  FoxNet  written  in  SML  (Buhler  1995)  suffers  up  to  30%  loss  of  throughput  due  to  checksum 
operation,  which  is  largely  composed  of  run-time  array  bound  checks.  The  SPIN  kernel  written  in 
Modula-3  (Bershad,  Savage,  Pardyak,  Sirer,  Becker,  Fiuczynski,  Chambers,  and  Eggers  1995)  also 
suffers  some  significant  performance  losses  from  run-time  array  bounds  checking.  The  traditional 
ad  hoc  approaches  to  eliminating  run-time  array  bound  checks  are  based  on  flow  analysis  (Gupta 
1994;  Kolte  and  Wolfe  1995).  A  significant  advantage  of  these  approaches  is  that  they  can  be 
made  fully  automatic,  requiring  no  programmer  supplied  annotations.  On  the  other  hand,  these 
approaches  in  general  have  very  limited  power.  For  instance,  they  cannot  eliminate  array  bound 
checks  involved  with  an  array  index  whose  value  is  not  monotonic  during  the  execution.  Also 
they  all  rely  on  whole  program  analysis,  having  some  fundamental  difficulty  crossing  over  module 
boundaries.  Another  serious  criticism  of  these  approaches  is  that  they  in  general  do  not  provide 
the  programmer  with  feedback  on  why  some  array  bound  checks  cannot  be  eliminated  (if  there  are 
still  some  left  after  the  flow  analysis).  In  other  words,  these  approaches,  though  may  enhances  the 
performance  of  the  programs,  cannot  lead  to  more  robust  programs.  Therefore,  they  offer  virtually 
no  software  engineering  benefits. 

In  this  section,  we  show  that  dependent  types  can  facilitate  the  elimination  of  run-time  array 
bound  checks.  Our  approach  requires  that  the  programmer  supply  type  annotations  in  the  code. 
In  return,  it  is  much  more  powerful  than  traditional  approaches.  For  instance,  we  will  show  how 
to  completely  eliminate  array  bound  checks  in  a  binary  search  function,  which  seems  beyond  the 
reach  of  any  practical  approach  based  on  flow  analysis.  In  addition,  our  approach  can  provide 
the  programmer  with  the  feedback  on  why  certain  array  bound  checks  cannot  be  eliminated. 
This  enhances  not  only  the  performance  of  the  programs  but  also  their  robustness.  Therefore, 
our  approach  offers  some  software  engineering  benefits.  Since  our  approach  is  orthogonal  to  the 
traditional  ones,  it  seems  straightforward  to  adopt  our  approach  at  type-checking  stage  and  then 
use  one  based  on  flow  analysis  at  code  generation  stage,  combining  the  benefits  of  dependent  types 
and  ffow  analysis  together. 

In  the  standard  basis  we  have  refined  the  types  of  many  common  functions  on  integers  such  as 
addition,  subtraction,  multiplication,  division,  and  the  modulo  operation.  Please  refer  to  Figure  8.1 
in  Chapter  8  for  more  details. 

In  order  to  eliminate  array  bound  checks  at  compile-time,  we  assume  that  the  array  operations 
sub  and  update  have  been  assigned  the  following  types. 

sub  <|  {n:nat]-  {i:nat  |  i  <  n}  ’a  array(n)  *  int(i)  ->  ’a 

update  <|  fn:nat}  {i:nat  |  i  <  n}  ’a  array(n)  *  int(i)  *  ’a  ->  unit 
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fun-[size  :nat} 

dotprod(vl,  v2)  = 
let 

fun  loop(i,  n,  sum)  = 
if  i  =  n  then  sum 

else  loop(i+l,  n,  sum  +  sub(vl,  i)  *  sub(v2,  i)) 
where  loop  <|  {i:nat  |  i  <=  size}  int(i)  *  int(size)  *  int  ->  int 
in 

loop(0,  length  vl,  0) 

end 

where  dotprod  <|  int  array(size)  *  int  array(size)  ->  int 


Figure  9.2:  The  dot  product  function 

Clearly,  we  are  sure  that  the  array  accesses  through  sub  or  update  cannot  result  in  array  bound 
violations,  and  therefore  there  is  no  need  for  inserting  array  bound  checks  when  we  compile  the 
code. 

Similarly,  we  can  assign  nth  the  following  type,  where  nth,  when  given  a  list  and  a  nonnegative 
integer  i,  returns  the  ith  element  in  the  list. 

sub  <|  {n:nat}  {i:nat  |  i  <  n}  ’a  list(n)  *  int(i)  ->  ’a 

This  can  eliminate  list  tag  checks  in  the  implementation  of  nth. 

The  code  in  Figure  9.2  is  an  implementation  of  the  dot  product  function.  We  use  {n:nat}  as  an 
explicit  universal  quantifier  or  dependent  function  type  constructor.  Conditions  may  be  attached, 
so  they  can  be  used  to  describe  certain  forms  of  subset  types,  such  as  {n:nat  |  i  <  n}  in  the  types 
of  sub  and  update.  The  two  “where”  clauses  are  present  in  the  code  for  type-checking  purposes, 
giving  the  dependent  type  of  the  local  tail- recursive  function  loop  and  the  function  dotprod  itself. 

This  could  be  a  simple  example  for  some  approaches  based  on  flow  analysis  since  the  index  i 
in  the  code  is  always  increasing.  Now  let  us  see  an  example  which  is  challenging  for  approaches 
based  on  flow  analysis.  The  code  in  Figure  1.3  is  an  implementation  of  binary  search  on  an  array. 
We  have  listed  in  Figure  3.4  some  sample  constraints  generated  from  type-checking  the  code.  All 
of  these  can  be  solved  easily. 

Note  that  if  we  program  binary  search  in  C,  the  array  bound  check  cannot  be  hoisted  out  of 
loops  using  the  algorithm  presented  in  (Gupta  1994)  since  it  is  neither  increasing  nor  decreasing  in 
terms  of  the  definition  given  there.  On  the  other  hand,  the  method  in  (Susuki  and  Ishihata  1977) 
could  eliminate  this  array  bound  check  by  synthesizing  an  induction  hypothesis  similar  to  our 
annotated  type  for  look.  Unfortunately,  synthesizing  induction  hypotheses  is  often  prohibitively 
expensive  in  practice.  In  future  work  we  plan  to  investigate  extensions  of  the  type-checker  which 
could  infer  certain  classes  of  generalizations,  thereby  relieving  the  programmer  from  the  need  for 
certain  kinds  of  “obvious”  annotations. 

9.2.1  Experiments 

We  have  performed  some  experiments  on  a  small  set  of  programs.  Note  that  three  of  them  (bcopy, 
binary  search,  and  quicksort)  were  written  by  others  and  just  annotated,  providing  evidence  that 
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Program 

number 

constraints 
SML  of  NJ 

MLWorks 

type  annotations 
total  number  total  lines 

code  size 

bcopy 

187 

0.59/1.17 

0.72/1.37 

13 

50 

281  lines 

binary  search 

13 

0.07/0.02 

0.10/0.04 

2 

2 

33  lines 

bubble  sort 

15 

0.08/0.03 

0.11/0.06 

3 

3 

37  lines 

matrix  mult 

18 

0.10/0.04 

0.16/0.06 

5 

10 

50  lines 

queen 

18 

0.11/0.03 

0.14/0.04 

9 

9 

81  lines 

quick  sort 

135 

0.29/0.58 

0.37/0.68 

16 

40 

200  lines 

hanoi  towers 

29 

0.10/0.09 

0.13/0.13 

4 

10 

45  lines 

list  access 

4 

0.07/0.01 

0.08/0.01 

2 

3 

18  lines 

Table  9.1:  Constraint  generation/solution,  time  in  secs 


a  natural  ML  programming  style  is  amenable  to  our  type  refinements. 

The  first  set  of  experiments  were  done  on  a  Dec  Alpha  3000/600  using  SML  of  New  Jersey 
version  109.32.  The  second  set  of  experiments  were  done  on  a  Sun  Sparc  20  using  MLWorks 
version  1.0.  Sources  of  the  programs  can  be  found  in  (Xi  1997). 

Table  9.1  summarizes  some  characteristics  of  the  programs.  We  show  that  the  number  of 
constraints  generated  during  type-checking  and  the  time  taken  for  generating  and  solving  them 
using  SML  of  New  Jersey  and  MLWorks.  Also  we  indicate  the  number  of  total  type  annotations 
in  the  code,  the  number  of  lines  they  occupy,  and  the  code  size.  Note  that  some  of  the  type 
annotations  are  already  present  in  non-dependent  form  in  ML,  depending  on  programming  style 
and  module  interface  to  the  code.  A  brief  description  of  the  programs  is  given  below. 

bcopy  This  is  an  optimized  implementation  of  the  byte  copy  function  used  in  the  Fox  project. 

We  used  this  function  to  copy  1M  bytes  of  data  10  times  in  a  byte-by-byte  style. 

binary  search  This  is  the  usual  binary  search  function  on  an  integer  array.  We  used  this  function 
to  look  for  220  randomly  generated  numbers  in  a  randomly  generated  array  of  size  220. 

bubble  sort  This  is  the  usual  bubble  sort  function  on  an  integer  array.  We  used  this  function  to 
sort  a  randomly  generated  array  of  size  213. 

matrix  mult  This  is  a  direct  implementation  of  the  matrix  multiplication  function  on  two-dimensional 
integer  arrays.  We  applied  this  function  to  two  randomly  generated  arrays  of  size  256  x  256. 

queen  This  is  a  variant  of  the  well-known  eight  queens  problem  which  requires  positioning  eight 
queens  on  a  8  x  8  chessboard  without  one  being  captured  by  another.  We  used  a  chessboard 
of  size  12  x  12  in  our  experiment. 

quick  sort  This  implementation  of  the  quick  sort  algorithm  on  arrays  is  copied  from  the  SML  of 
New  Jersey  library.  We  sorted  a  randomly  generated  integer  array  of  size  220. 

hanoi  towers  This  is  a  variant  of  the  original  problem  which  requires  moving  64  disks  from  one 
pole  to  another  without  stacking  a  larger  disk  onto  a  smaller  one  given  the  availability  of  a 
third  pole.  We  used  24  disks  in  our  experiments. 
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Program 

with  checks 

without  checks 

gain 

checks  eliminated 

bcopy 

6.52 

4.40 

32% 

20,971,520 

binary  search 

40.40 

30.10 

25% 

19,072,212 

bubble  sort 

58.90 

34.25 

42% 

134,429,940 

matrix  mult 

30.62 

16.79 

45% 

33,619,968 

queen 

15.85 

11.06 

30% 

77,392,496 

quick  sort 

29.85 

25.32 

15% 

64,167,588 

hanoi  towers 

11.34 

8.28 

27% 

50,331,669 

list  access 

2.24 

1.24 

45% 

1,048,576 

Table  9.2:  Dec  Alpha  3000/600  using  SML  of  NJ  working  version  109.32,  time  unit  =  sec. 


Program 

with  checks 

without  checks 

gain 

checks  eliminated 

bcopy 

9.75 

2.01 

79% 

20,971,520 

binary  search 

31.78 

25.00 

21% 

19,074,429 

bubble  sort 

46.78 

25.84 

45% 

134,654,868 

matrix  mult 

60.43 

51.27 

15% 

33,619,968 

queen 

29.81 

14.81 

50% 

77,392,496 

quick  sort 

79.95 

70.28 

12% 

63,035,841 

hanoi  towers 

9.59 

7.20 

25% 

50,331,669 

list  access 

1.58 

0.77 

51% 

1,048,576 

Table  9.3:  Sun  Sparc  20  using  MLWorks  version  1.0,  time  unit  =  sec. 


list  access  We  accessed  the  first  sixteen  elements  in  a  randomly  generated  list  at  total  of  220 
times. 

We  used  the  standard,  safe  versions  of  sub  and  update  for  array  access  when  compiling  the  pro¬ 
grams  into  the  code  with  array  bound  checks.  These  versions  always  perform  run-time  array  bound 
checks  according  to  the  semantics  of  Standard  ML.  We  used  unsafe  versions  of  sub  and  update  for 
array  access  when  generating  the  code  containing  no  array  bound  checks.  These  functions  can  be 
found  in  the  structure  Unsafe  .Array  (in  SML  of  New  Jersey),  and  in  MLWorks  .  Internal  .Value  (in 
MLWorks).  Our  unsafe  version  of  the  nth  function  used  cast  for  list  access  without  tag  checking. 

Notice  that  unsafe  versions  of  sub,  update  and  nth  can  be  used  in  our  implementation  only  if 
they  are  assigned  the  corresponding  types  mentioned  previously. 

In  Table  9.2  and  Table  9.3,  we  present  the  effects  of  eliminating  array  bound  checks  and  list  tag 
checks.  Note  that  the  difference  between  the  number  of  eliminated  array  bound  checks  in  Table  9.2 
and  Table  9.3  reflects  the  difference  between  randomly  generated  arrays  used  in  two  experiments. 

We  also  present  two  diagrams  in  Figure  9.3  and  Figure  9.4.  The  height  of  a  bar  stands  for  the 
time  spent  on  the  experiment.  The  gray  ones  are  for  the  experiments  in  which  all  array  bound 
checks  are  eliminated  at  compile-time  and  the  dark  ones  for  the  others. 

It  is  clear  that  the  gain  is  significant  in  all  cases,  rewarding  the  work  of  writing  type  annotations. 
In  addition,  type  annotations  can  be  very  helpful  for  finding  and  fixing  certain  program  errors,  and 
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Figure  9.3:  Dec  Alpha  3000/600  using  SML  of  NJ  working  version  109.32 


for  maintaining  a  software  system  since  they  provide  the  user  with  informative  documentation.  We 
feel  that  these  factors  yield  a  strong  justification  for  our  approach. 


9.3  Potential  Applications 

In  this  section  we  present  some  potential  applications  of  dependent  types,  which  have  yet  to  be 
implemented.  We  also  outline  some  approaches  to  realizing  these  applications.  We  refer  the  reader 
to  (Xi  1999)  for  further  details  regarding  the  subject  on  dead  code  elimination. 

9.3.1  Dead  Code  Elimination 

The  following  function  zip  zips  two  lists  together.  If  the  clause  zip  (_,  _)  =  raise  zipException 
is  missing,  then  some  ML  compiler  will  issue  a  warning  message  stating  that  zip  may  result  in  a 
match  exception  to  be  raised.  For  instance,  this  happens  if  two  arguments  of  zip  are  of  different 
lengths. 

exception  zipException 
fun(’a,  ;b) 

zip(nil,  nil)  =  nil 

I  zip(cons(x,  xs) ,  cons(y,  ys))  =  cons((x,y),  zip(xs,  ys)) 

I  zip(_,  _)  =  raise  zipException 

However,  this  function  is  meant  to  zip  two  lists  of  equal  length.  If  we  declare  that  zip  is  of  the 
following  dependent  type, 


{n:nat}  ’a  list(n)  *  ’b  list(n)  ->  Ca  *  b’)  list(n) 
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Figure  9.4:  Sun  Sparc  20  using  MLWorks  version  1.0 


then  the  clause  zip(_,  _)  =  raise  zipException  in  the  definition  of  zip  can  never  be  reached, 
and  therefore  can  be  safely  removed.  In  other  words,  we  can  declare  the  function  zip  as  follows. 

fun(’a,  Jb) 

zip(nil,  nil)  =  nil 

I  zip(cons(x,  xs) ,  cons(y,  ys))  =  cons((x,y),  zip(xs,  ys)) 
where  {n:nat]-  ’a  list(n)  *  ’b  list(n)  ->  (’a  *  b’)  list(n) 

This  leads  to  not  only  more  compact  but  also  possibly  more  efficient  code.  For  instance,  if  it 
has  been  checked  that  the  first  argument  of  zip  is  nil .  then  it  can  return  the  result  nil  immediately 
since  it  is  redundant  to  check  whether  the  second  argument  is  nil  (it  must  be). 

We  now  prove  a  lemma,  which  provides  the  key  to  eliminating  redundant  matching  clauses. 

n  s 

Lemma  9.3.1  Given  a  pattern  p  and  a  type  r  in  ML0  ’  (C)  such  that  p  [  r  >  (0;  T)  is  derivable. 
If  ;■  h  v  :  t  and  match(u,p)  h  6  are  derivable,  then  <p  |=  _L  is  not  satisfiable.  In  other  words,  if 
(f  \=  _L  is  derivable,  then  there  is  no  closed  value  of  type  r  which  can  match  the  pattern  p. 

Proof  If  (f)  |=  _L  is  satisfiable,  then  (</>)_L  holds  in  the  constraint  domain  C.  It  can  be  readily 
verified  that  a  counterexample  to  (0)_L  can  be  given  if  we  let  a  be  8(a)  for  all  a  £  dom(^).  If 
(j>  \=  T  is  derivable,  then  (f>  |=  _L  is  satisfiable  by  definition.  Therefore,  there  is  no  closed  value  v  of 
type  t  which  matches  the  pattern  p  if  <f>  \=  _L  is  derivable.  ■ 
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Let  us  call  an  index  variable  context  (f>  inconsistent  if  (f>  |=  _L  is  satisfiable.  Lemma  9.3.1  simply 
implies  that  no  closed  value  of  type  r  can  match  a  pattern  p  if  checking  p  against  r  yields  an 
inconsistent  index  variable  context. 

Therefore,  when  the  following  rule  is  applied  during  elaboration, 

P  in=>  (p*-,(f> i;Ti)  (j),(f)f-T,Ti  h  e  |  r2  =>[^]  <L 

4>,  if  h  T\  =$■  T2  :  *  (f>,  ij)  h  T[ctx] 

7  (constr-match) 

4>;  T  h  (p  =>  e)  |  (n  =>•  r2)  =KY>]  V($f  ).4> 

we  verify  whether  (f>,  (jff  |=  _L  is  derivable.  If  it  is,  then  the  matching  clause  p  =>■  e  can  never  be 
reached.  We  can  either  issue  a  warning  message  at  this  point  or  safely  remove  the  matching  clause. 

However,  there  is  a  serious  issue  which  must  be  dealt  with  before  we  can  apply  this  strategy  to 
pattern  matching  in  ML.  The  operational  semantics  of  ML  requires  that  pattern  matching  be  done 
sequentially.  For  instance,  if  the  third  clause  zip(_,  _)  in  the  first  declaration  of  zip  is  chosen  to  eval¬ 
uate  zip(v),  then  v  must  not  match  either  pattern  (nil,  nil)  or  (cons(x,  xs ),  cons(y,  ys )).  Therefore, 
v  matches  either  pattern  ( cons(x ,  xs),nil)  or  (nil,  cons(y ,  ys)).  If  v  is  of  type  (a)list(n)  *  (P)list(n) 
for  some  n,  this  is  clearly  impossible.  This  example  suggests  that  we  transform  overlapped  match¬ 
ing  clauses  into  disjoint  ones  before  detecting  whether  some  of  them  are  redundant.  In  the  above 
case,  this  amounts  to  transforming  the  first  declaration  of  zip  into  the  following  one. 

exception  zipException 
fun(’a,  ;b) 

zip(nil,  nil)  =  nil 

I  zip(cons(x,  xs) ,  cons(y,  ys))  =  cons((x,y),  zip(xs,  ys)) 

I  zip(nil,  cons(y,  ys))  =  raise  zipException 
I  zip(cons(x,  xs) ,  nil)  =  raise  zipException 

Let  us  assign  zip  the  type  Aa.Af3.Pn  :  nat.(a)list(n)  *  ((3)list(n)  — >  (a  *  (3)list(n).  Notice  that  we 
have 


(nil,  cons(y,  ys))  j  (a)list(n)  *  ((3)list(n)  >  (0  =  n,  a  :  nat,  a  +  1  =  n;  y  :  f3,  ys  :  (/ 3)list(a )) 

Since  n  :  nat,  0  =  n,  a  :  nat,  a  +  1  =  n  |=  _L  is  derivable,  the  third  clause  is  redundant  by 
Lemma  9.3.1.  Similarly,  the  fourth  clause  is  also  unreachable. 

This  approach  seems  to  be  straightforward,  but  it  can  lead  to  code  size  explosion  when  applied 
to  certain  examples.  Therefore,  we  are  still  in  search  of  a  better  solution  to  detecting  unreachable 
matching  clauses. 

9.3.2  Loop  Unrolling 

In  this  subsection  we  present  another  potential  application  of  dependent  types,  following  some  ob¬ 
servation  in  Subsection  9.3.1.  The  following  declared  function  sum  Array  sums  up  all  the  elements 
in  a  given  integer  array. 

fun{n:nat} 

sumArray (arr)  = 
let 
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fun  loop(i,  n,  s)  =  if  i  =  n  then  s  else  loop(i+l,  n,  sub(arr,  i)+s) 
where  loop  <|  {i:nat  |  i  <=  n}  int(i)  *  int(n)  *  int  ->  int 
in 

loop(0,  length (arr) ,  0) 

end 

where  sumArray  <|  int  array (n)  ->  int 

Note  that  if  i  =  n  then  s  else  loop(i+l,  n,  sub(arr,  i)+s)  is  a  variant  of  the  following 
case  statement. 

case  i  =  n  of  true  =>  s  |  false  =>  loop(i+l,  n,  sub(arr,  i)+s) 

We  now  declare  another  function  sum  Array‘d  as  follows,  that  is,  sum  Array'S  can  only  be  applied 
to  an  integer  array  of  size  8. 

fun  sumArray8(arr)  =  sumArray (arr) 
where  sumArray  <|  int  array (8)  ->  int 

Then  it  seems  reasonable  that  we  can  expand  the  declaration  to  the  following  through  partial 
evaluation.  We  give  some  informal  explanation. 

fun  sumArray8(arr)  = 

sub(arr,  7)  +  (sub(arr,  6)  +  (sub(arr,  5)  +  (sub(arr,  4) 

(sub(arr,  3)  +  (sub(arr,  2)  +  (sub(arr,  1)  +  (sub(arr,  0)  +  0))))))) 
where  sumArray  <|  int  array (8)  ->  int 

If  arr  is  of  type  (int)array( 8),  then  length(arr)  is  of  type  inf (8)  since  length  is  given  the 
type  Aa.IIn  :  nat.(a)array(n)  — >  int(n).  After  expanding  loop(0,length(arr),0 )  to  let  n  = 
lengt.h(arr)  in  loop(0,n,  0)  end  (this  is  a  call-by-value  language!),  the  type  of  n  must  be  inf (8). 
We  now  expand  loop( 0,  n,  0)  to 

case  0  =  n  of  true  =>•  0  |  false  =>•  loop( 0  +  1,  n,  sub(arr,  0)  +  0) 

Notice  that  the  type  of  0  =  n  is  bool( 0  =  8)  since  =  is  of  the  following  type. 

Ilm  :  inf.IIn  :  int.intfm ,)  *  inf(n)  — »  bool(m  =  n) 

Therefore,  according  to  the  reasoning  in  Section  9.3.1,  the  matching  clause  true  0  is  unreachable. 
This  allows  the  simplification  of  the  above  case  statement  to  loop( 0  +  l,n,sub(arr,0)  +  0).  By 
repeating  this  process  eight  times,  we  reach  the  expanded  declaration  of  sum  Arr  ay  8.  This  can 
lead  to  more  efficient  code  without  sacrificing  clarity. 

However,  if  the  size  of  an  integer  array  arr  is  a  large  natural  number,  it  may  not  be  advantageous 
to  expand  sumArray(arr)  since  this  can  result  in  unexpected  instruction  cache  behavior  and  thus 
slow  down  the  code  execution.  We  propose  a  possible  solution  as  follows. 

A  significant  problem  with  currently  available  programming  languages  is  that  there  exist  few 
approaches  to  improving  the  efficiency  of  code  without  overhauling  the  entire  code.  With  the  help 
of  partial  evaluation,  this  situation  can  be  somewhat  ameliorated  as  follows.  We  assume  that  the 
programmer  decides  to  write  the  function  sum Array _unr oil  in  Figure  9.5  to  replace  sumArray 
for  the  sake  of  efficiency.  Though  much  more  involved  than  the  example  about  sumArray8,  we 
expect  that  loop_8_times  can  specialize  to  the  following  function  with  partial  evaluation. 
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fun{n:nat} 

sumArray_unroll (arr)  = 
let 

fun  loop(i,  n,  s)  =  if  i  =  n  then  s  else  loop(i+l,  n,  sub(arr,  i)+s) 
where  loop  <|  {i:nat  |  i  <=  n}  int(i)  *  int(n)  ->  int 

fun  loop_8_times (i ,  n,  s)  =  loop(i,  n,  s) 
where  loop_8_times  <| 

{i:nat  |  i  <=  n  /\  n  mod  8=0}  int(i)  *  int(n)  ->  int 
in 

let 

val  n  =  length (arr) 
and  r  =  n  %  8 
in 

loop(n-r,  n,  loop_8_times (0 ,  n-r,  0)) 

end 

end 

where  sumArray_unroll  <|  int  array (n)  ->  int 


Figure  9.5:  loop  unrolling  for  sumArray 


fun  loop_8_times (i ,  n,  s)  = 
if  i  =  n  then  s 
else  loop_8_times(i+8,  n, 

sub(arr,  i+7)+(sub(arr ,  i+6)+ 

(sub(arr,  i+5)+(sub(arr ,  i+4)+ 

(sub (arr,  i+3)+(sub(arr ,  i+2)+ 

( sub (arr,  i+l)+s) ) ) ) ) ) ) 

where  loop_8_times  <|  {i:nat  |  i  <=  n  /\  n  mod  8=0}  int(i)  *  int(n)  ->  int 

This  roughly  corresponds  to  loop-unrolling,  a  well-known  technique  in  compiler  optimization. 
Though  we  have  not  shown  that  loop  unrolling  done  above  preserves  the  operational  semantics,  we 
think  that  this  is  a  straightforward  matter.  Now  it  seems  reasonable  to  gain  some  performance  by 
expanding  sumArray  _unr  oil  (arr)  for  arr  of  large  known  size.  The  interested  reader  is  referred  to 
(Draves  1997)  for  some  realistic  and  interesting  examples  which  may  be  handled  in  this  way. 

Combining  dependent  types  with  partial  evaluation,  we  hope  to  find  an  approach  to  improving 
the  efficiency  of  existing  code  with  only  moderate  amount  of  modification.  This  is  currently  an 
exciting  but  highly  speculative  research  direction. 

9.3.3  Dependently  Typed  Assembly  Language 

The  studies  on  the  use  of  types  in  compilation  have  been  highly  active  recently.  For  instance,  the 
work  in  (Morrisett  1995;  Tarditi,  Morrisett,  Cheng,  Stone,  Harper,  and  Lee  1996;  Tolmach  and 
Oliva  1998;  Morrisett,  Walker,  Crary,  and  Glew  1998)  has  demonstrated  convincing  evidence  to 
support  the  use  of  typed  intermediate  and  assembly  languages  for  various  purposes  such  as  data 
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int  dotprod(int  A[]  ,  int  B[],  int  n)  { 
int  i ,  sum ; 
sum  =  0; 

for(i  =0;  i  <  n;  i++)  {  sum  +=  A [i]  *  B [i] ;  } 
return  sum; 

> 


Figure  9.6:  The  C  version  of  dotprod  function 


layout,  tag-free  garbage  collection,  compiler  error  detection,  etc.  This  immediately  indicates  that 
it  would  be  beneficial  if  we  could  pass  dependent  types  to  lower  level  languages  during  compilation. 
Many  compiler  optimizations  involving  code  motion  may  then  benefit  from  the  use  of  dependent 
types.  Array  bound  check  elimination  through  dependent  types  in  Section  9.2  is  a  solid  support  of 
this  argument. 

We  have  started  to  formulate  a  dependently  typed  assembly  language,  which  is  mainly  inspired 
by  (Morrisett,  Walker,  Crary,  and  Glew  1998).  The  theory  of  this  language  is  yet  to  be  developed. 
We  now  use  an  example  to  informally  present  some  ideas  behind  this  research.  The  following  code 
in  Figure  9.6  is  an  implementation  of  dot  product  function  in  C .  It  is  written  in  this  way  so 
that  it  can  be  directly  compared  with  the  code  in  Figure  9.7,  which  is  an  implementation  of  dot 
product  function  in  DTAL,  a  dependently  typed  assembly  language.  Note  that  “\\”  starts  a  line 
of  comment. 

In  DTAL,  each  label  is  associated  with  a  type.  For  instance,  the  label  dotprod  is  associated 
with  the  following  type. 

{n:  natj  [rO:  int  array (n) ,  rl:  int  array (n) ,  r3:  int(n)] 

Roughly  speaking,  this  type  means  that  when  the  execution  of  the  code  reaches  the  label  dotprod, 
the  registers  rO  and  rl  must  point  to  integer  arrays  of  size  n  for  some  natural  number  n  and  r3 
stores  an  integer  equal  to  n. 

The  DTAL  code  has  been  type-checked  in  a  prototype  implementation.  Notice  that  the  type 
system  guarantees  that  there  is  no  memory  violation  when  the  command  load  r4,  r0(r2)  is 
executed  since  the  value  in  r2  is  a  natural  number  less  than  the  size  of  the  array  to  which  rO 
points.  Therefore,  if  the  code  is  downloaded  from  an  untrusted  source  and  type-checked  locally, 
no  run-time  checks  are  needed  for  preventing  possible  memory  violations.  This  opens  an  exciting 
avenue  to  eliminating  array  bound  checks  for  programming  languages  such  as  Java,  which  run  on 
networks.  More  examples  of  DTAL  code  can  be  found  in  (Xi  1998). 


9.4  Summary 

We  have  so  far  presented  some  applications  of  dependent  types.  The  uses  of  dependent  types  in 
program  error  detection  and  array  bound  check  elimination  have  been  put  into  practice.  Though 
it  seems  relatively  straightforward  to  use  dependent  types  for  eliminating  unreachable  matching 
clauses  or  issuing  more  accurate  warning  messages  about  inexhausitive  pattern  matching,  but  this 
is  yet  to  be  implemented.  Also  we  have  speculated  that  it  could  be  beneficial  to  combine  partial 
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dotprod:{n:  nat}  \\  n  is  universally  quantified 

[rO:  int  array (n) ,  rl :  int  array (n) ,  r3:  int(n)] 

\\  rO  and  rl  point  to  integer  arrays  A  and  B  of  size  n,  respectively 
\\  and  n  is  stored  in  r3 

mov  r31,  0  \\  set  r31  to  0 
mov  r2,  0  \\  set  r2  to 

jmp  loop  \\  start  the  loop 

loop:  {n:nat,  i:int  |  0  <=  i  <=  n} 

\\  n  and  i  are  universally  quantified  and  0  <=  i  <=  n 

[rO:  int  array (n) ,  rl :  int  array (n) ,  r2:int(i),  r3:  int(n),  r31:  int] 
\\  r2  =  i  and  r3  =  n 

r2,  r3  \\  compare  r2  and  r3 

\\  r2  is  not  equal  to  r3 
load  r4,  r0(r2)  \\  load  A[i]  into  r4 

load  r5,  rl(r2)  \\  load  B [i]  into  r5 

mul  r4,  r4,  r5  \\  r4  =  r4  *  r5 

add  r31,  r31,  r4  \\  r31  =  r31  +  r4 

add  r2,  r2,  1  \\  increase  r2  by  1 

jmp  loop  \\  repeat  the  loop 

\\  r2  is  equal  to  n 
jmp  finish  \\  done 

finish:  [r31:  int]  \\  r31  stores  the  result,  which  is  an  integer 
halt 

Figure  9.7:  The  DTAL  version  of  dotprod  function 


cmp 

ifnz 


else 

endif 
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evaluation  with  dependent  types,  demonstrating  informally  that  loop- unrolling  may  be  controlled 
by  the  programmer  with  dependent  types. 

It  is  both  promising  and  highly  desirable  to  spot  more  concrete  opportunities  in  compiler 
optimization  which  could  benefit  from  dependent  types. 


Chapter  10 


Conclusion 


and  Future  Work 


The  dependent  type  inference  developed  in  this  thesis  has  demonstrated  convincing  signs  of  being 
a  viable  system  for  practical  use.  Compared  to  ML-types,  dependent  types  can  more  accurately 
capture  program  invariants  and  therefore  lead  to  detecting  more  program  errors  at  compile-time. 
Also,  the  use  of  dependent  types  in  array  bound  check  elimination  is  encouraging  since  this  can 
enhance  not  only  the  robustness  but  also  the  efficiency  of  programs. 

As  with  any  programming  language,  DML  has  many  weak  points.  Some  of  the  weak  points 
result  from  the  trade-offs  made  to  ensure  the  practicality  of  dependent  type  inference,  and  some  can 
be  remedied  through  further  experiment  and  research.  In  this  chapter  we  summarize  the  current 
research  status  on  incorporating  dependent  types  into  ML  and  point  out  some  directions  to  pursue 
in  the  future  to  make  DML  a  better  programming  language. 

10.1  Current  Status 

We  briefly  mention  the  current  status  of  DML  in  terms  of  both  language  design  and  language 
implement  at  ion . 

10.1.1  Language  Design 

We  have  so  far  finished  extending  the  core  of  ML  with  a  notion  of  dependent  types,  that  is, 
combining  dependent  types  with  language  features  such  as  datatype  declarations,  higher-order 
functions,  let-polymorphism,  references  and  exceptions.  The  extended  language  is  given  the  name 
DML  (for  Dependent  ML).  Strictly  speaking,  DML  is  really  a  language  parameterized  over  a  given 
constraint  domain  C  and  thus  should  be  denoted  by  DML(C).  We  may  omit  writing  the  constraint 
domain  C  in  the  following  presentation,  and  if  we  do  so  then  we  mean  that  the  omitted  C  is  the 
integer  constraint  domain  presented  in  Section  3.3,  or  C  is  simply  irrelevant. 

We  have  proven  the  soundness  of  the  enriched  type  system  and  then  constructed  a  practical 
type-checking  algorithm  for  it.  Furthermore,  the  correctness  of  the  type-checking  algorithm  is  also 
established.  This  has  placed  our  work  on  a  solid  theoretical  foundation. 

DML  is  a  conservative  extension  of  ML  in  the  sense  that  a  DML  program  which  uses  no 
dependent  types  is  simply  a  valid  ML  program.  In  order  to  make  DML  fully  compatible  with  the 
core  of  ML,  we  designed  a  two-phase  type-checking  algorithm  for  DML.  This  guarantees  that  an 
ML  program  (written  in  some  external  language  for  ML)  can  always  pass  type-checking  for  DML 
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if  it  passes  the  type-checking  for  ML.  Therefore,  the  programmer  can  use  sparingly  the  features 
related  to  dependent  types  when  writing  (large)  programs. 

10.1.2  Language  Implementation 

We  have  finished  a  prototype  implementation  of  a  type-checker  for  a  substantial  part  of  DML(C), 
where  C  is  the  integer  constraint  domain  in  Section  3.3.  This  part  roughly  corresponds  to  the  lan¬ 
guage  MLg’^’^ref(C')  introduced  in  Section  7.4,  including  most  features  in  the  core  of  ML  such  as 
higher-order  functions,  datatypes,  let-polymorphism,  references  and  exceptions.  However,  records 
have  yet  to  be  implemented.  It  should  be  straightforward  to  include  records  in  a  future  implemen¬ 
tation  since  they  are  simply  a  variant  of  products.  All  examples  in  Chapter  A  have  been  verified 
in  this  implementation. 

The  constraint  solver  for  the  integer  domain  is  based  on  a  variant  of  the  Fourier-Motzkin 
variable  elimination  approach  (Dantzig  and  Eaves  1973).  This  is  an  intuitive  and  clean  approach, 
which  we  think  is  more  promising  than  those  based  on  SUP-INF  or  the  simplex  method  to  report 
comprehensible  and  accurate  type  error  or  warning  messages  on  unsatisfiable  constraints,  a  vital 
component  for  type-checking  in  DML(C).  The  weak  aspect  of  this  approach  is  that  it  seems  less 
promising  to  handle  large  contraints  than  the  Simplex  method,  but  this  issue  needs  to  be  further 
investigated. 

10.2  Future  Research  in  Language  Design 

In  this  section,  we  present  some  future  research  directions  for  improving  DML. 

10.2.1  Modules 

Since  we  have  finished  adding  dependent  types  to  the  core  of  ML,  namely,  ML  without  module 
level  constructs,  the  next  move  is  naturally  to  study  the  interaction  between  the  module  system 
of  ML  and  dependent  types.  There  are  many  intricate  issues  which  can  only  be  answered  in 
practice.  An  immediate  question  is  how  to  export  dependent  types  in  signature.  Since  there  is 
no  notion  of  principal  types  in  DML,  a  function  can  be  assigned  two  dependent  types  neither  of 
which  coerces  into  the  other.  For  instance,  the  following  declared  function  tail  can  be  assigned 
types  Va.(En  :  nat.(a)list(n ))  — >  En  :  nat.(a)list(n)  and  Va.nn  :  nat.(a)list(n  +  1)  — >  ( a)list(n ), 
respectively. 

fun  tail (cons (x,  xs))  =  x 

The  second  type  cannot  be  coerced  into  the  first  one  since  a  function  of  the  first  type  can  be  applied 
to  any  list  while  a  function  of  the  second  type  can  only  be  applied  to  a  non-empty  list.  If  the  length 
of  a  list  l  cannot  be  inferred  from  static  type-checking,  then  only  the  first  assigned  type  can  be 
used  if  we  need  to  type-check  tail{l).  However,  if  l  is  inferred  to  be  not  empty  at  compile-time, 
the  use  of  the  second  type  can  lead  to  potentially  more  efficient  code  as  explained  in  Section  9.3.1. 
At  this  moment,  we  contemplate  introducing  a  notion  of  top-level  conjunction  types  into  DML.  In 
the  above  case,  we  would  like  to  assign  tail  the  following  conjunction  types 

(Va.(En  :  nat.(a)list(n))  — >■  En  :  nat.(a)list(n ))  A  (Va.nn  :  nat.(a)list(n  +  1)  — >  ( a)list(n )) 
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Then  the  programmer  is  allowed  to  choose  which  type  is  needed  for  an  occurrence  of  tail.  There 
are  yet  many  details  to  be  filled  in  and  some  experience  to  be  gained  on  this  issue. 

10.2.2  Combination  of  Different  Refinements 

We  currently  require  that  a  datatype  be  refined  at  most  once.  However,  there  are  also  cases  where 
a  datatype  may  need  different  refinements  for  different  purposes.  For  instance,  we  encountered 
a  case  where  we  needed  to  refine  the  datatype  (( a)list)list  with  a  pair  of  index  objects  (i,j)  to 
represent  the  length  of  a  list  of  lists  and  the  sum  of  the  lengths  of  the  lists  in  this  list  of  lists.  It 
is  not  clear  how  this  refinement  could  be  done  since  the  datatype  ( a)list  has  already  been  refined 
with  an  index  which  stands  for  the  length  of  a  list.  Instead,  we  declared  the  following  datatype, 
refined  it  and  then  substituted  it  for  (( a)list)list . 

datatype  ’a  listlist  =  Nil  |  Cons  of  ’a  list  *  ’a  listlist 
typeref  J  a  listlist  of  nat  *  nat 
with  Nil  <|  ’a  listlist (0 , 0) 

I  Cons  <|  fl :nat ,m:nat ,n:nat} 

’a  list(l)  *  'a  listlist (m,n)  ->  Ja  listlist (m+1 ,n+l) 

This  resulted  in  substituting  Nil  and  Cons  for  nil  and  cons  in  many  places  of  a  program,  respec¬ 
tively.  More  details  can  be  found  in  the  example  on  merge  sort  presented  in  Section  A. 4.  It  is  a 
future  research  topic  to  study  how  to  combine  several  different  refinements  of  a  datatype. 

10.2.3  Constraint  Domains 

The  general  constraint  language  in  Section  3.1  allows  the  programmer  to  declare  the  constraint 
domain  C  over  which  the  language  DML(C)  is  parameterized.  Then,  by  Theorem  5.2.7,  the  type¬ 
checking  in  DML(C)  can  be  reduced  to  constraint  satisfaction  in  C.  Unfortunately,  there  is  no 
method  available  to  enable  the  programmer  to  supply  a  constraint  solver  for  C. 

Therefore,  it  is  highly  desirable  to  provide  the  programmer  with  a  language  in  which  a  constraint 
solver  can  be  written.  A  programmer-supplied  constraint  solver  for  constraint  domain  C  can  then 
be  combined  with  elaboration  so  that  type-checking  for  DML(C)  can  be  performed. 

10.2.4  Other  Programming  Languages 

Another  research  direction  is  to  apply  the  language  design  approach  in  this  thesis  to  other  (strongly 
typed)  programming  languages  such  as  Haskell(Peyton  Jones  et  al.  1999)  and  Java(Sun  Microsys¬ 
tems  1995).  Array  bound  check  elimination  in  Java,  however,  requires  some  special  care,  as  we 
explain  now.  A  program  in  Java  is  often  compiled  into  Java  Virtual  Machine  Language  (JVML) 
code  and  shipped  through  networks.  Since  JVML  code  can  be  downloaded  by  a  local  host  which 
does  not  trust  the  source  of  the  code,  there  must  be  some  evidence  attached  to  the  code  in  order 
to  convince  the  local  host  that  it  is  safe  to  eliminate  array  bound  checks  in  the  code.  An  approach 
presented  in  (Necula  1997)  is  to  make  the  code  carry  a  proof  of  certain  properties  of  the  code 
which  can  be  verified  by  the  local  host,  leading  to  the  notion  of  proof-carrying  code.  In  practice, 
the  proof  carried  by  code  may  tend  to  be  difficult  to  construct  and  large  when  compared  to  the  size 
of  the  code.  Another  approach,  following  (Morrisett,  Walker,  Crary,  and  Glew  1998),  is  to  make 
the  compiled  code  explicitly  typed  with  dependent  types  so  that  code  properties  can  be  verified 
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by  the  local  host  equipped  with  a  type-checker  for  dependent  types.  This  leads  to  the  notion  of 
dependently  typed  assembly  language. 

10.2.5  Denotational  Semantics 

n  e 

We  are  also  interested  in  constructing  a  categorical  model  for  the  language  ML0  ’  ( C ).  Various 

denotational  models  based  on  the  notion  of  locally  closed  cartesian  categories  have  already  been 

constructed  for  A-calculi  with  fully  dependent  type  systems  such  as  the  one  which  underlies  LF 

(Harper,  Honsell,  and  Plotkin  1993).  However,  ML0  ’  ( C )  is  essentially  different  from  these  A- 

calculi  because  of  the  separation  between  type  index  objects  and  language  expressions.  We  expect 

n  e 

that  a  model  tailored  for  ML0  ’  (C)  would  yield  some  semantic  explanation  on  index  erasure,  which 
simply  cannot  exist  in  a  fully  dependent  type  setting. 

10.3  Future  Implementations 

The  present  prototype  implementation  exhibits  many  aspects  for  immediate  improvement.  For 
instance,  we  have  observed  that  a  large  percentage  of  the  constraints  can  be  solved  immediately 
after  their  generation.  However,  we  currently  collect  all  constraints  generated  during  elaboration 
in  a  constraint  store  before  we  call  a  constraint  solver.  This  practice  often  leads  to  inflating  the 
number  of  constraints  significantly  at  the  stage  where  all  constraints  are  transformed  into  some 
standard  form.  Therefore,  it  seems  promising  that  elaboration  can  be  done  much  more  efficiently 
if  we  intertwine  constraint  generation  with  constraint  solution. 

Another  observation  is  that  an  overwhelming  majority  of  integer  constraints  generated  during 
elaboration  are  trivial  and  can  be  solved  with  a  constraint  solver  which  is  highly  efficient  but 
incomplete,  such  as  a  constraint  solver  based  the  simplex  method  for  real  numbers.  After  filtering 
out  the  trivial  constraints,  we  can  then  use  a  complete  constraint  solver  such  as  the  one  mentioned 
in  (Pugh  and  Wonnacott  1992)  to  solve  the  rest  of  constraints.  A  similar  strategy  has  been  adopted 
in  the  constraint  logic  programming  community  for  efficiently  solving  constraints. 

A  certifying  compiler  for  Safe  C,  a  programming  language  with  similar  constructs  to  part  of  C, 
is  presented  in  (Necula  and  Lee  1998).  At  this  stage,  the  compiler  largely  relies  on  synthesizing  loop 
invariants  in  code  in  order  to  verify  certain  properties  such  as  memory  integrity.  This  approach, 
however,  seems  difficult  to  cope  with  large  programs.  On  the  other  hand,  the  type  system  of  DML 
is  strong  enough  for  allowing  the  programmer  to  supply  loop  invariants  through  type  annotations. 
This  gives  DML  a  significant  advantage  when  the  scalability  issue  is  concerned.  Therefore,  it  is 
natural  to  consider  whether  a  certifying  compiler  for  DML  can  be  implemented  in  the  future. 
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A.l  Knuth-Morris-Pratt  String  Matching 

The  following  is  an  implementation  of  the  Knuth-Morris-Pratt  string  matching  algorithm  using 
dependent  types  to  eliminate  most  array  bound  checks. 

structure  KMP  = 
struct 

assert  length  <|  {n:nat}  ’  a  array  (n)  ->  int(n) 

and  sub  <|  (*  sub  requires  NO  bound  checking  *) 

{size: int,  i:int  |  0  <=  i  <  size}  ’a  array (size)  *  int(i)  ->  ’a 

and  subCK  <|  (*  subCK  requires  bound  checking  *) 

’a  array  *  int  ->  ’a 

(*  notice  the  use  of  existential  types  *) 

type  intPrefix  =  [i : int I  0  <=  i+1]  int(i) 

assert  arrayPrefix  <| 

{size:nat}  int(size)  *  intPrefix  ->  intPrefix  array(size) 

and  subPrefix  <|  (*  subPrefix  requires  NO  bound  checking  *) 

{size: int,  i:int  |  0  <=  i  <  size} 
intPrefix  array (size)  *  int(i)  ->  intPrefix 

and  subPrefixCK  <|  (*  subPrefixCK  requires  bound  checking  *) 
intPrefix  array  *  int  ->  intPrefix 

and  updatePrefix  <|  (*  updatePrefix  requires  NO  bound  checking  *) 

{size: int,  i:int  |  0  <=  i  <  size} 

intPrefix  array (size)  *  int(i)  *  intPrefix  ->  unit 
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(* 

*  computePref ixFunction  generates  the  prefix  function 

*  table  for  the  pattern  pat 
*) 

fun  computePref ixFunction (pat)  = 
let 

val  plen  =  length (pat) 

val  prefixArray  =  arrayPref ix(plen,  ~1) 

fun  loop(i,  j)  =  (*  calculate  the  prefix  array  *) 
if  (j  >=  plen)  then  () 
else 

if  sub (pat,  j)  <>  subCK(pat,  i+1)  then 

if  (i  >=  0)  then  loop(subPref ixCK(pref ixArray ,  i) ,  j) 
else  loop(~l,  j+1) 

else  (updatePrefix (prefixArray,  j,  i+1); 

loop(subPrefix(pref ixArray,  j),  j+1)) 
where  loop  <|  {j:nat}  intPrefix  *  int(j)  ->  unit 
in 

(loop(~l,  1);  prefixArray) 

end 

where  computePref ixFunction  <|  {p:nat]-  int  array(p)  ->  intPrefix  array(p) 

fun  kmpMatch(str ,  pat)  = 
let 

val  strLen  =  length(str) 
and  patLen  =  length (pat) 

val  prefixArray  =  computePref ixFunction (pat) 
fun  loop(s,  p)  = 

if  s  <  strLen  then 
if  p  <  patLen  then 

if  sub(str,  s)  =  sub (pat,  p)  then  loop(s+l,  p+1) 
else 

if  (p  =  0)  then  loop(s+l,  p) 
else  loop(s,  subPrefix (pref ixArray ,  p-l)+l) 
else  (s  -  patLen) 
else  ~1 

where  loop  <|  {s:nat,  p:nat}  int(s)  *  int(p)  ->  int 
in 

loop(0,  0) 

end 

where  kmpMatch  <|  {s:nat,  p:nat}  int  array(s)  *  int  array(p)  ->  int 


end 
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A. 2  Red/Black  Tree 

(* 

*  This  example  shows  that  the  insert  operation  maps  a  balanced 

*  red/black  tree  into  a  balanced  one.  Also  it  increases  the  size 

*  of  the  tree  by  at  most  one  (note  that  the  inserted  key  may  have 

*  already  existed  in  the  tree) .  There  8  type  annotations  occupying 

*  about  20  lines. 

*) 

structure  RedBlackTree  = 
struct 

type  key  =  int 

type  answer  =  key  option 

type  ’ a  entry  =  int  *  ’ a 

datatype  order  =  LESS  |  EQUAL  I  GREATER 
datatype  ’a  diet  = 

Empty  (*  considered  black  *) 

I  Black  of  'a  entry  *  ’a  diet  *  ’a  diet 
I  Red  of  ’a  entry  *  ’a  diet  *  ’a  diet 


(* 

*  We  refine  the  datatype  ’a  diet  with  an  index  of  type 

*  (nat  *  nat  *  nat  *  nat) .  The  meaning  of  the  4  numbers 

*  is:  (color,  black  height,  red  height,  size).  A  balanced 

*  tree  is  one  such  that 

*  (1)  for  every  node  in  it,  both  of  its  sons  are  of  the 

*  same  black  height. 

*  (2)  the  red  height  of  the  tree  is  0,  which  means  that  there  exist 

no  consecutive  red  nodes. 

*) 

typeref  ’a  diet  of  nat  *  nat  *  nat  *  nat  with 
Empty  <|  ’a  dict(0,  0,  0,  0) 

I  Black  < | 

{cl: nat,  cr:nat,  bh:nat,  si: nat,  srmat} 

’a  entry  *  ’a  dict(cl,  bh,  0,  si)  *  Ja  dict(cr,  bh,  0,  sr)  -> 

;a  dict(0,  bh+1,  0,  sl+sr+1) 

I  Red  <|  {cl  mat,  cr:nat,  bh:nat,  rhl:nat,  rhr:nat,  si  mat,  srmat} 
’a  entry  *  ’a  dict(cl,  bh,  rhl,  si)  *  'a  dict(cr,  bh,  rhr,  sr)  -> 
;a  dict(l,  bh,  cl+cr+rhl+rhr ,  sl+sr+1) 


(*  note  if  the  root  of  a  tree  is  black,  then  the  tree  is  a  balanced  *) 
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fun  compare  (si : int , s2 : int)  = 

if  si  >  s2  then  GREATER  else  if  si  <  s2  then  LESS  else  EQUAL 
where  compare  < |  int  *  int  ->  order 

fun( ’ a) 

lookup  diet  key  = 
let 

fun  lk  (Empty)  =  NONE 

I  lk  (Red  tree)  =  lkJ  tree 
I  lk  (Black  tree)  =  lk’  tree 
where  lk  < |  ’a  diet  ->  answer 

and  lkJ  ((keyl,  datuml) ,  left,  right)  = 

(case  compare(key,keyl)  of 
EQUAL  =>  SOME(keyl) 

I  LESS  =>  lk  left 
I  GREATER  =>  lk  right) 

where  lk’  <|  ’a  entry  *  ’a  diet  *  ’a  diet  ->  answer 
in 

lk  diet 

end 

where  lookup  <|  ’a  diet  ->  key  ->  answer 
fun( ’ a) 

restore_right (e ,  Red  It,  Red  (rt  as  (_,Red  _,_)))  = 

Red(e,  Black  It,  Black  rt) (*  re-color  *) 

I  restore_right (e ,  Red  It,  Red  (rt  as  (_,_,Red  _)))  = 

Red(e,  Black  It,  Black  rt) (*  re-color  *) 

I  restore_right (e ,  1  as  Empty,  Red(re,  Red(rle,  rll,  rlr) ,  rr))  = 
Black(rle,  Red(e,  1,  rll),  Red(re,  rlr,  rr)) 

I  restore_right (e ,  1  as  Black  _,  Red(re,  Red(rle,  rll,  rlr),  rr))  = 
(*  1  is  black,  deep  rotate  *) 

Black(rle,  Red(e,  1,  rll),  Red(re,  rlr,  rr)) 

I  restore_right (e ,  1  as  Empty,  Red (re,  rl,  rr  as  Red  _))  = 

Black(re,  Red(e,  1,  rl) ,  rr) 

I  restore_right (e ,  1  as  Black  _,  Red(re,  rl,  rr  as  Red  _))  = 

(*  1  is  black,  shallow  rotate  *) 

Black(re,  Red(e,  1,  rl) ,  rr) 

I  restore_right (e ,  1,  r  as  Red(_,  Empty,  Empty))  =  Black (e,  1,  r) 
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I  restore_right (e ,  1,  r  as  Red(_,  Black  Black  _))  = 

Black(e,  1,  r)  (*  r  must  be  a  red/black  tree  *) 

I  restore_right (e ,  1,  r  as  Black  _)  = 

Black(e,  1,  r)  (*  r  must  be  a  red/black  tree  *) 

where  restore_right  < I 

-[cl:nat,  cr:nat,  bh:nat,  rhr:nat,  sl:nat,  sr:nat  |  rhr  <=  1} 

’a  entry  *  ’a  dict(cl,  bh,  0,  si)  *  ’a  dict(cr,  bh,  rhr,  sr)  -> 
[c:nat  |  c  <=  1  ]  ’a  dict(c,  bh+1,  0,  si  +  sr  +  1) 

fun( ’ a) 

restore_lef t (e ,  Red  (It  as  (_,Red  Red  rt)  = 

Red(e,  Black  It,  Black  rt) (*  re-color  *) 

I  restore_lef t (e ,  Red  (It  as  (_,_,Red  _)),  Red  rt)  = 

Red(e,  Black  It,  Black  rt) (*  re-color  *) 

I  restore_lef t (e ,  Red(le,  11  as  Red  _,  lr) ,  r  as  Empty)  = 

Black(le,  11,  Red(e,  lr,  r)) 

I  restore_lef t (e ,  Red(le,  11  as  Red  _,  lr) ,  r  as  Black  _)  = 

(*  r  is  black,  shallow  rotate  *) 

Black(le,  11,  Red(e,  lr,  r)) 

I  restore_lef t (e ,  Red(le,  11,  Red(lre,  lrl,  lrr)),  r  as  Empty)  = 
Black(lre,  Red(le,  11,  lrl),  Red(e,  lrr,  r)) 

I  restore_lef t (e ,  Red(le,  11,  Red(lre,  lrl,  lrr)),  r  as  Black  _)  = 
(*  r  is  black,  deep  rotate  *) 

Black(lre,  Red(le,  11,  lrl),  Red(e,  lrr,  r)) 

I  restore_lef t (e ,  1  as  Red(_,  Empty,  Empty),  r)  =  Black(e,  1,  r) 

I  restore_lef t (e ,  1  as  Red(_,  Black  _,  Black  _) ,  r)  = 

Black(e,  1,  r)  (*  1  must  be  a  red/black  tree  *) 

I  restore_lef t (e ,  1  as  Black  _,  r)  = 

Black(e,  1,  r)  (*  1  must  be  a  red/black  tree  *) 

where  restore_lef t  < I 

{cl:nat,  cr:nat,  bh:nat,  rhl:nat,  sl:nat,  sr:nat  |  rhl  <=  1} 

’a  entry  *  ’a  dict(cl,  bh,  rhl,  si)  *  ’a  dict(cr,  bh,  0,  sr)  -> 
[c:nat  |  c  <=  1  ]  ’a  dict(c,  bh+1,  0,  si  +  sr  +  1) 
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exception  Item_Is_Found 
fun( ’ a) 

insert  (diet,  entry  as  (key , datum) )  = 
let 

(*  val  ins  :  ’a  diet  ->  ’a  diet  inserts  entry 

*  ins  (Red  _)  may  violate  color  invariant  at  root, 

*  having  red  height  1 

*  ins  (Black  _)  or  ins  (Empty)  will  always  be  red/black 

*  ins  always  preserves  black  height 
*) 

fun  ins  (Empty)  =  Red (entry.  Empty,  Empty) 

I  ins  (Red(entryl  as  (keyl,  datuml) ,  left,  right))  = 

(case  compare(key,keyl)  of 

EQUAL  =>  raise  Item_Is_Found 
I  LESS  =>  Red(entryl,  ins  left,  right) 

I  GREATER  =>  Red(entryl,  left,  ins  right)) 

I  ins (Black(entryl  as  (keyl,  datuml),  left,  right))  = 

(case  compare(key,keyl)  of 

EQUAL  =>  raise  Item_Is_Found 
I  LESS  =>  restore_left (entryl ,  ins  left,  right) 

I  GREATER  =>  restore_right (entryl ,  left,  ins  right)) 
where  ins  < | 

{c:nat,  bh:nat,  s:nat} 

’a  dict(c,  bh,  0,  s)  -> 

[nc : nat ,  nrh : nat  | 

((c  =  0  /\  nrh  =  0  /\  nc  <=  1)  \/  (c  =  1  /\  nrh  <=  1  /\  nc  =  1))] 
’a  dict(nc,  bh,  nrh,  s+1) 
in 

let 

val  diet  =  ins  diet 
in 

case  diet  of 

Red  (t  as  (_,  Red  _,  _))  =>  Black  t  (*  re-color  *) 

I  Red  (t  as  (_,  _,  Red  _))  =>  Black  t  (*  re-color  *) 

I  Red  (t  as  (_,  Black  _,  Black  _))  =>  diet 

I  Red  (t  as  (_,  Empty,  Empty))  =>  diet 

I  Black  _  =>  diet 
end  handle  Item_Is_Found  =>  diet 

end 

where  insert  < | 

{c:nat,  bh:nat,  s:nat} 

’  a  dict(c,  bh,  0,  s)  *  ’a  entry  -> 

[nc : nat ,  nbh : nat ,  ns : nat  | 
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(nbh  =  bh  \/  nbh  =  bh  +  1)  /\  (ns  =s\/ns=s+l)  ] 
’a  dict(nc,  nbh,  0,  ns) 

end 


A. 3  Quicksort  on  Arrays 

(* 

*  This  example  shows  that  array  bounds  checking  is  not  required  in 

*  the  following  implementation  of  an  in-place  quicksort  algorithm 

*  on  arrays.  The  code  is  copied  from  SML/NJ  lib  with  some  modification. 

*  There  are  16  type  annotations  occupying  about  40  lines. 

*) 


structure  Array_QSort  = 
struct 

datatype  order  =  LESS  |  EQUAL  I  GREATER 


assert  sub  < | 
and  update  < | 
and  length  < | 


{n:nat,  i:nat  |  i  <  n  }  ’a  array(n)  *  int(i)  ->  'a 
{n:nat,  i:nat|  i  <  n  }  J  a  array (n)  *  int(i)  *  ’a  ->  unit 
{n:nat}  ’a  array (n)  ->  int(n) 


fun( ,a){size :nat} 

sortRange (arr ,  start,  n,  cmp)  = 

let 

fun  item  i  =  sub (arr, i) 

where  item  <|  {i:nat  |  i  <  size  }  int(i)  ->  'a 


fun  swap  (i,j)  = 
let 

val  tmp  =  item  i 
in 

update (arr,  i,  item  j);  update (arr,  j,  tmp) 

end 

where  swap  < I 

{i:nat,  j :nat  |  i  <  size  /\  j  <  size  }  int(i)  *  int(j)  ->  unit 
fun  vecswap  (i,j,n)  = 

if  (n  =  0)  then  ()  else  (swap(i , j ) ; vecswap(i+l , j+1 ,n-l) ) 
where  vecswap  <| 

{i:nat,  j:nat,  n:nat  |  i+n  <=  size  /\  j+n  <=  size} 
int(i)  *  int(j)  *  int(n)  ->  unit 

(* 

*  insertSort  is  called  if  there  are  less  than 
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*  eight  elements  to  be  sorted 
*) 

fun  insertSort  (start,  n)  = 
let 

val  limit  =  start+n 
fun  outer  i  = 

if  i  >=  limit  then  () 
else 

let 

fun  inner  j  = 

if  j  <=  start  then  outer (i+1) 
else 

let 

val  j 5  =  j  -  1 
in 

case  cmp(item  j’.item  j)  of 

GREATER  =>  (swap(j,j’);  inner  jJ) 

I  _  =>  outer(i+l) 

end 

where  inner  <|  {j:nat  |  j  <  size  }  int(j)  ->  unit 
in 

inner  i 

end 

where  outer  <|  {i:nat}  int(i)  ->  unit 
in 

outer (start+1) 

end 

where  insertSort  < | 

{start :nat,  n:nat  I  start+n  <=  size  }  int (start)  *  int(n)  ->  unit 

(*  calculate  the  median  of  three  *) 
fun  med3(a,b,c)  = 
let 

val  a’  =  item  a 
val  b’  =  item  b 
val  c’  =  item  c 
in 

case  (cmp(a’,  b’),cmp(b’,  c’))  of 
(LESS,  LESS)  =>  b 

I  (LESS,  _)  =>  (case  cmp(a’ ,  c’)  of  LESS  =>  c  |  =>  a) 

I  (_,  GREATER)  =>  b 

I  _  =>  (case  cmp(a’ ,  c’)  of  LESS  =>  a  |  _  =>  c) 

(*  end  case  *) 

end 

where  med3  < | 
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{a:nat,b:nat,c:nat  |  a  <  size  /\  b  <  size  /\  c  <  size  } 
int(a)  *  int(b)  *  int(c)  ->  [n:nat  |  n  <  size  ]  int(n) 

(*  generate  the  pivot  for  splitting  the  elements  *) 
fun  getPivot  (a,n)  = 

if  n  <=  7  then  a  +  n  div  2 
else 

let 

val  pi  =  a 
val  pm  =  a  +  n  div  2 
val  pn  =  a  +  n  -  1 
in 

if  n  <=  40  then  med3(pl ,pm,pn) 
else 

let 

val  d  =  n  div  8 
val  pi  =  med3(pl ,pl+d,pl+2*d) 
val  pm  =  med3(pm-d,pm,pm+d) 
val  pn  =  med3(pn-2*d,pn-d,pn) 
in 

med3(pl ,pm,pn) 

end 

end 

where  getPivot  < | 

{a:nat ,n:nat  |  1  <  n  /\  a  +  n  <=  size  } 
int(a)  *  int(n)  ->  [p:nat  |  p  <  size]  int(p) 

fun  quicksort  (arg  as  (a,  n))  = 
let 

(* 

*  bottom  was  defined  as  a  higher  order 

*  function  in  the  SML/NJ  library 
*) 

fun  bottomQimit ,  arg  as  (pa,  pb))  = 
if  pb  >  limit  then  arg 
else 

case  cmp(item  pb,item  a)  of 
GREATER  =>  arg 

I  LESS  =>  bottom(limit ,  (pa,  pb+1)) 

I  _  =>  (swap  arg;  bottom(limit ,  (pa+1 ,pb+l) ) ) 
where  bottom  < | 

{l:nat,  ppa:nat,  ppb:nat  | 

1  <  size  /\  ppa  <=  ppb  <=  1+1  } 
int(l)  *  (int(ppa)  *  int(ppb))  -> 

[pa:nat,  pb:nat  |  ppa  <=  pa  <=  pb  <=  1+1] 
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(int(pa)  *  int(pb)) 

(* 

*  top  was  defined  as  a  higher  order 

*  function  in  the  SML/NJ  library 
*) 

fun  top (limit,  arg  as  (pc,  pd))  = 
if  limit  >  pc  then  arg 
else  case  cmp(item  pc, item  a)  of 
LESS  =>  arg 

I  GREATER  =>  top(limit,  (pc-l,pd)) 

I  _  =>  (swap  arg;  top(limit,  (pc-1 ,pd-l) ) ) 
where  top  < | 

{l:nat,  ppc:nat,  ppd:nat  | 

0  <  1  <=  ppc+1  /\  ppc  <=  ppd  <  size  } 
int(l)  *  (int(ppc)  *  int(ppd))  -> 

[pc:nat,  pd:nat  |  1  <=  pc+1  /\  pc  <=  pd  <=  ppd] 
(int(pc)  *  int(pd)) 

fun  split  (pa,pb,pc,pd)  = 
let 

val  (pa,pb)  =  bottom(pc,  (pa,pb)) 
val  (pc,pd)  =  top(pb,  (pc,pd)) 
in 

if  pb  >=  pc  then  (pa,pb,pc ,pd) 

else  (swap(pb,pc) ;  split (pa, pb+1 , pc-1 ,pd) ) 

end 

where  split  <| 

{ppa:nat,  ppb:nat,  ppc:nat,  ppd:nat  | 

0  <  ppa  <=  ppb  <=  ppc+1  /\  ppc  <=  ppd  <  size  } 
int(ppa)  *  int(ppb)  *  int(ppc)  *  int(ppd)  -> 

[pa:nat,  pb:nat,  pc:nat,  pd:nat  | 
ppa  <=  pa  <=  pb  <=  pc+1  /\  pc  <=  pd  <=  ppd  ] 

(int(pa)  *  int(pb)  *  int(pc)  *  int(pd)) 

val  pm  =  getPivot  arg 
and  _  =  swap (a, pm) 
and  pa  =  a  +  1 
and  pc  =  a  +  (n-1) 

and  (pa,pb ,pc ,pd)  =  split(pa,pa,pc,pc) 
and  pn  =  a  +  n 

val  r  =  min (pa  -  a,  pb  -  pa) 
val  _  =  vecswap(a,  pb-r,  r) 
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val  r  =  min(pd  -  pc,  pn  -  pd  -  1) 
val  _  =  vecswap(pb,  pn-r,  r) 

val  n’  =  pb  -  pa 

val  _  =  (if  n’  >  1  then  sort (a, n’)  else  ())  <|  unit 
val  n’  =  pd  -  pc 

val  _  =  (if  n’  >  1  then  sort (pn-n’ ,nJ )  else  ())  <|  unit 

in  ()  end 
where  quicksort  <| 

{a:nat,  n:nat  |  7  <=  n  /\  a+n  <=  size  }  int(a)  *  int(n)  ->  unit 

and  sort  (arg  as  (_,  n) )  = 

if  n  <  7  then  insertSort  arg 
else  quicksort  arg 
where  sort  < | 

{a:nat,  n:nat  |  a+n  <=  size  }  int(a)  *  int(n)  ->  unit 
in 

sort  (start, n) 

end 

where  sortRange  < | 

{start :nat,  n:nat  |  start +n  <=  size  } 

’a  array (size)  *  int (start)  *  int(n)  *  ('a  *  ’a  ->  order)  ->  unit 

(*  sorted  checks  if  a  list  is  well-sorted  *) 
f un( ’ a) {size : nat} 
sorted  cmp  arr  = 
let 

val  len  =  length  arr 
fun  s(v,i)  = 
let 

val  v’  =  sub (arr, i) 
in 

case  cmp(v,v’)  of 

GREATER  =>  false 

I  =>  if  i+1  =  len  then  true  else  s(v’,i+l) 

end 

where  s  <|  {i:nat  |  i  <  size  }  'a  *  int(i)  ->  bool 
in 

if  len  <=  1  then  true  else  s(sub(arr,0) , 1) 

end 

where  sorted  <|  (’a  *  ’a  ->  order)  ->  ’a  array (size)  ->  bool 
end  (*  end  of  the  structure  *) 
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A. 4  Mergesort  on  Lists 

structure  Merge_Sort  = 
struct 

datatype  'a  listlist  =  Nil  |  Cons  of  'a  list  *  ’a  listlist 
typeref  'a  listlist  of  nat  *  nat 
with  Nil  <|  ’a  listlist (0 , 0) 

I  Cons  <|  {1 :nat ,m:nat ,n:nat} 

’a  list(l)  *  ’a  listlist (m,n)  ->  ’a  listlist (m+1 ,n+l) 

assert  not  < |  bool  ->  bool 

and  rev  <|  {n:nat}  'a  list(n)  ->  ’a  list(n) 
and  hd  < |  {  n:nat  |  n  >  0  }  ’a  list(n)  ->  ’a 

fun( ’ a) 

sort  cmp  Is  = 
let 

fun  merge ([] ,ys)  =  ys 
I  merge  (xs ,  [] )  =  xs 
I  merge (x: :xs,y: :ys)  = 

if  cmp(x,y)  then  y: : merge (x: :xs,ys) 
else  x: :merge(xs,y: :ys) 
where  merge  < | 

{m:nat,  n:nat}  'a  list(m)  *  'a  list(n)  ->  'a  list(m+n) 

fun  mergepairs ’ (Is  as  Cons (1, Nil))  =  1 
I  mergepairs' (Cons (11, Cons (12, Is)))  = 
mergepairs ’ (Cons (merge (11 , 12) , Is) ) 
where  mergepairs ’  < | 

{m:nat,  n:nat  |  m  >  0}  ’a  listlist (m,n)  ->  'a  list(n) 

fun  mergepairs (Is  as  Cons(l,Nil),  k)  =  Is 
I  mergepairs (Cons (11, Cons (12, Is)) ,k)  = 
if  k  mod  2=1  then  Cons (11 , Cons (12 , Is) ) 
else  mergepairs (Cons (merge (11 , 12) , Is) ,  k  div  2) 
where  mergepairs  < | 

{m : nat ,  n : nat  |  m  >  0} 

'a  listlist (m,n)  *  int  ->  [m:nat  |  m  >  0]  'a  listlist (m,n) 

fun  nextrun(run,  [] )  =  (rev  run,[]) 

I  nextrun(run,x: :xs)  = 

if  cmp(x,hd(run) )  then  nextrun(x: :run,xs) 
else  (rev  run,x: :xs) 
where  nextrun  < | 

{m : nat ,  n : nat  |  m  >  0  } 
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’a  list(m)  *  ’a  list(n)  -> 

[p:nat,  q:nat  |  p+q  =  m+n]  (’ a  list(p)  *  ’a  list(q)) 


fun  samsorting( [] ,  Is,  k)  =  mergepairs ’ (Is) 

I  samsorting(x : :xs,  Is,  k)  = 
let 

val  (run, tail)  =  nextrunC [x] ,xs) 
in 

samsorting(tail ,  mergepairs (Cons (run, Is) ,k+l) ,  k+1) 

end 

where  samsorting  <| 

{1 :nat ,m:nat ,n:nat  |  m+1  >  0} 

’a  list(l)  *  ’a  listlist (m,n)  *  int  ->  ’a  list(n+l) 
in 

case  Is  of  []  =>  []  |  =>  samsorting (Is ,  Nil,  0) 

end 

where  sort  <|  {n:nat}  (’a  *  ’a  ->  bool)  ->  ’a  list(n)  ->  ’a  list(n) 
fun( ’ a) 

sorted  (cmp)  = 
let 

fun  s  (x::(rest  as  (y::_)))  =  not (cmp (x,  y))  andalso  s  rest 
I  s  1  =  true 

where  s  <|  ’a  list  ->  bool 

in  s  end 

where  sorted  <|  ('a  *  J a  ->  bool)  ->  ;a  list  ->  bool 
end  (*  end  of  mergeSort  *) 

A. 5  A  Byte  Copy  Function 

This  implementation  of  a  byte  copy  function  is  used  in  the  Fox  project. 

(*  This  is  an  optimized  version  of  byte  copy  function  used  in  the  Fox 

*  project.  All  the  array  bound  checks  can  be  eliminated.  There  are 

*  13  type  annotations,  which  consists  of  roughly  20%  of  the  code 
*) 

structure  BCopy  = 
struct 

assert  subl  <|  {n:nat,  i:nat|  i  <  n  }  array(n)  *  int(i)  ->  bytel 
and  updatel  <| 

{n:nat,  i:nat|  i  <  n  }  array (n)  *  int(i)  *  bytel  ->  unit 
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assert  sub2  <|  {n:nat,  i:nat|  i  +  1  <  n  }  array (n)  *  int(i)  ->  byte2 
and  update2  <| 

{n:nat,  i:nat|  i  +  1  <  n  }  array (n)  *  int(i)  *  byte2  ->  unit 

assert  sub4  <|  {n:nat,  i:nat|  i  +  3  <  n  }  array (n)  *  int(i)  ->  byte4 
and  update4  < | 

{n:nat,  i:nat|  i  +  3  <  n  }  array (n)  *  int(i)  *  byte4  ->  unit 

assert  «  <  |  byte4  *  int  ->  byte4 

and  II  <|  byte4  *  byte4  ->  byte4 

and  »  < |  byte4  *  int  ->  byte4 

fun{m:nat,  n:nat,  endsrc :nat} 

unaligned (src ,  srcpos,  endsrc,  dest,  destpos)  = 
let 

fun  loop(i,j)  = 

if  (i  >=  endsrc)  then  () 

else  (updatel (dest ,  j,  subl(src,  i));  loop(i+l,  j+1)) 
where  loop  < | 

{i:nat,  j  :nat  |  j  +  endsrc  -  i  <=  n  }  int(i)  *  int(j)  ->  unit 
in 

loop(srcpos,  destpos) 

end 

where  unaligned  <| 

{srcpos :nat ,  destpos :nat  |  endsrc  <=  m  /\  destpos  +  endsrc  -  srcpos  <=  n  } 
array(m)  *  int(srcpos)  *  int(endsrc)  *  array(n)  *  int(destpos)  ->  unit 

fun{m:nat,  n:nat,  endsrc :nat} 

common(src,  srcpos,  endsrc,  dest,  destpos)  = 

case  endsrc  -  srcpos  of 

1  =>  (updatel (dest ,  destpos,  subl(src,  srcpos))) 

I  2  =>  (updatel (dest ,  destpos,  subl(src,  srcpos)); 

updatel (dest ,  destpos+1,  subl(src,  srcpos+1))) 

I  4  =>  (updatel (dest ,  destpos,  subl(src,  srcpos)); 

updatel (dest ,  destpos+1,  subl(src,  srcpos+1)); 
updatel (dest ,  destpos+2,  subl(src,  srcpos+2)); 
updatel (dest ,  destpos+3,  subl(src,  srcpos+3))) 

I  8  =>  (updatel (dest ,  destpos,  subl(src,  srcpos)); 

updatel (dest ,  destpos+1,  subl(src,  srcpos+1)); 
updatel (dest ,  destpos+2,  subl(src,  srcpos+2)); 
updatel (dest ,  destpos+3,  subl(src,  srcpos+3)); 
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updatel (dest ,  destpos+4,  subl(src,  srcpos+4)); 
updatel (dest ,  destpos+5,  subl(src,  srcpos+5)); 
updatel (dest ,  destpos+6,  subl(src,  srcpos+6)); 
updatel (dest ,  destpos+7,  subl(src,  srcpos+7))) 

I  16  =>  (updatel (dest ,  destpos,  subl(src,  srcpos)); 

updatel (dest ,  destpos+1,  subl(src,  srcpos+1)); 
updatel (dest ,  destpos+2,  subl(src,  srcpos+2)); 
updatel (dest ,  destpos+3,  subl(src,  srcpos+3)); 
updatel (dest ,  destpos+4,  subl(src,  srcpos+4)); 
updatel (dest ,  destpos+5,  subl(src,  srcpos+5)); 
updatel (dest ,  destpos+6,  subl(src,  srcpos+6)); 
updatel (dest ,  destpos+7,  subl(src,  srcpos+7)); 
updatel (dest ,  destpos+8,  subl(src,  srcpos+8)); 
updatel (dest ,  destpos+9,  subl(src,  srcpos+9)); 
updatel (dest ,  destpos+10,  subl(src,  srcpos+10)); 
updatel (dest ,  destpos+11,  subl(src,  srcpos+11)); 
updatel (dest ,  destpos+12,  subl(src,  srcpos+12)); 
updatel (dest ,  destpos+13,  subl(src,  srcpos+13)); 
updatel (dest ,  destpos+14,  subl(src,  srcpos+14)); 
updatel (dest ,  destpos+15,  subl(src,  srcpos+15))) 

I  20  =>  (updatel (dest ,  destpos,  subl(src,  srcpos)); 

updatel (dest ,  destpos+1,  subl(src,  srcpos+1)); 
updatel (dest ,  destpos+2,  subl(src,  srcpos+2)); 
updatel (dest ,  destpos+3,  subl(src,  srcpos+3)); 
updatel (dest ,  destpos+4,  subl(src,  srcpos+4)); 
updatel (dest ,  destpos+5,  subl(src,  srcpos+5)); 
updatel (dest ,  destpos+6,  subl(src,  srcpos+6)); 
updatel (dest ,  destpos+7,  subl(src,  srcpos+7)); 
updatel (dest ,  destpos+8,  subl(src,  srcpos+8)); 
updatel (dest ,  destpos+9,  subl(src,  srcpos+9)); 
updatel (dest ,  destpos+10,  subl(src,  srcpos+10)); 
updatel (dest ,  destpos+11,  subl(src,  srcpos+11)); 
updatel (dest ,  destpos+12,  subl(src,  srcpos+12)); 
updatel (dest ,  destpos+13,  subl(src,  srcpos+13)); 
updatel (dest ,  destpos+14,  subl(src,  srcpos+14)); 
updatel (dest ,  destpos+15,  subl(src,  srcpos+15)); 
updatel (dest ,  destpos+16,  subl(src,  srcpos+16)); 
updatel (dest ,  destpos+17,  subl(src,  srcpos+17)); 
updatel (dest ,  destpos+18,  subl(src,  srcpos+18)); 
updatel (dest ,  destpos+19,  subl(src,  srcpos+19))) 

I  _  =>  unaligned (src ,  srcpos,  endsrc,  dest,  destpos) 
where  common  < | 
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{srcpos:nat,  destpos:nat  | 
endsrc  <=  m  /\  destpos  +  endsrc  -  srcpos  <=  n  } 
array(m)  *  int(srcpos)  *  int(endsrc)  *  array(n)  *  int(destpos)  ->  unit 

fun{m:nat,  n:nat,  endsrc :nat} 

sixteen(src,  srcpos,  endsrc,  dest,  destpos)  = 

let 

fun  loop(i,  j)  = 

if  i  >=  endsrc  then  () 
else 

(update4(dest,  j,  sub4(src,  i ) ) ; 
update4(dest ,  j+4,  sub4(src,  i+4)); 
update4(dest ,  j+8,  sub4(src,  i+8)); 
update4(dest ,  j+12,  sub4(src,  i+12)); 
loop(i+16,  j  +  16) ) 
where  loop  < | 

-[i:nat,  j  :nat  I  (endsrc  -  i)  mod  16  =  0  /\  j  +  endsrc  -  i  <=  n  } 
int(i)  *  int(j)  ->  unit 
in 

loop(srcpos,  destpos) 

end 

where  sixteen  < I 
{srcpos :nat ,  destpos :nat  | 
endsrc  <=  m  /\  (endsrc  -  srcpos)  mod  16  =  0  /\ 
destpos  +  endsrc  -  srcpos  <=  n  } 

array(m)  *  int(srcpos)  *  int(endsrc)  *  array(n)  *  int(destpos)  ->  unit 
f un{srcalign : nat} 

aligned(src,  srcpos,  endsrc,  dest,  destpos,  srcalign,  bytes)  = 
let 

val  front  = 

(case  srcalign  of 
0  =>  0 
I  1  =>  3 

I  2  =>  2 

I  3  =>  1)  <|  [i:nat  |  (srcalign  =  0  /\  i  =  0)  \/ 

(srcalign  =  1  /\  i  =  3)  \/ 

(srcalign  =  2  /\  i  =  2)  \/ 

(srcalign  =  3  /\  i  =  1) 

]  int(i) 

val  rest  =  bytes  -  front 
val  tail  =  rest  mod  16 
val  middle  =  rest  -  tail 
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val  midsrc  =  srcpos  +  front 
val  middest  =  destpos  +  front 

val  backsrc  =  midsrc  +  middle 
val  backdest  =  middest  +  middle 
in 

unaligned(src ,  srcpos,  midsrc,  dest,  destpos); 
sixteen(src,  midsrc,  backsrc,  dest,  middest); 
unaligned(src ,  backsrc,  endsrc,  dest,  backdest) 

end 

where  aligned  <| 

{m:nat,  n:nat,  srcpos :nat,  endsrc :nat,  destpos :nat,  bytes :nat  | 
endsrc  <=  m  /\  srcpos  +  bytes  =  endsrc  /\ 
destpos  +  bytes  <=  n  /\  16  <=  bytes  } 
array (m)  *  int (srcpos)  *  int (endsrc)  * 

array (n)  *  int (destpos)  *  int (srcalign)  *  int (bytes)  ->  unit 


fun{m:nat,  n:nat,  endsrc :nat} 

eightlittle (src ,  srcpos,  endsrc,  dest,  destpos)  = 
let 

assert  makebyte2  < |  byte4  ->  byte2 
and  makebyte4  < |  byte2  ->  byte4 

fun  loop(i,  j,  carry)  = 

if  i  >=  endsrc  then  update2(dest ,  j,  makebyte2 (carry) ) 
else 

let 

val  srcv  =  sub4(src,  i) 
in 

update4(dest ,  j,  | | (carry,  <<(srcv,  16))); 
let 

val  i  =  i  +  4 
val  j  =  j  +  4 
val  carry  =  »(srcv,  16) 
val  srcv  =  sub4(src,  i) 
in 

update4(dest ,  j,  | | (carry,  <<(srcv,  16))); 
loop(i+4,  j+4,  »(srcv,  16)) 

end 

end 

where  loop  < | 

{i :nat ,  j :nat  | 

i  <=  endsrc  /\  (endsrc  -  i)  mod  8  =  0  /\  j  +  endsrc  -  i  +  2  <=  n  } 
int(i)  *  int(j)  *  byte4  ->  unit 
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in 

loop(srcpos+2 ,  destpos,  makebyte4(sub2 (src ,  srcpos))) 

end 

where  eightlittle  <| 

{srcpos  mat ,  destpos  mat  | 
endsrc  <=  m  /\  srcpos  <=  endsrc  /\ 

(endsrc  -  srcpos)  mod  8  =  2  /\  destpos  +  endsrc  -  srcpos  <=  n  } 
array(m)  *  int(srcpos)  *  int(endsrc)  *  array(n)  *  int(destpos)  ->  unit 

fun{m:nat,  nmat,  endsrc  mat} 

eightbig(src ,  srcpos,  endsrc,  dest,  destpos)  = 
let 

assert  makebyte2  < |  byte4  ->  byte2 
and  makebyte4  < |  byte2  ->  byte4 

fun  loop(i,  j,  carry)  = 

if  i  >=  endsrc  then  update2 (dest ,  j,  makebyte2(» (carry,  16))) 
else 

let 

val  srcv  =  sub4(src,  i) 
in 

update4(dest ,  j,  I  |  (carry,  »(srcv,  16))); 
let 

val  i  =  i  +  4 
val  j  =  j  +  4 
val  carry  =  <<(srcv,  16) 
val  srcv  =  sub4(src,  i) 
in 

update4(dest ,  j,  | | (carry,  >>(srcv,  16))); 
loop(i  +4,  j  +  4,  <<(srcv,  16)) 

end 

end 

where  loop  < | 

{i  mat ,  j  mat  | 

i  <=  endsrc  /\  (endsrc  -  i)  mod  8  =  0  /\  j  +  endsrc  -  i  +  2  <=  n  } 
int(i)  *  int(j)  *  byte4  ->  unit 
in 

loop(srcpos  +  2,  destpos,  «(makebyte4(sub2(src,  srcpos)),  16)) 

end 

where  eightbig  < | 

{srcpos mat,  destpos mat  |  endsrc  <=  m  /\  srcpos  <=  endsrc  /\ 

(endsrc  -  srcpos)  mod  8  =  2  /\  destpos  +  endsrc  -  srcpos  <=  n  } 
array(m)  *  int(srcpos)  *  int(endsrc)  *  array(n)  *  int(destpos)  ->  unit 


assert  endian  <|  int  and  Little  <|  int 
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fun  eight (src,  srcpos,  endsrc,  dest,  destpos)  = 

if  endian  =  Little  then  eightbig(src ,  srcpos,  endsrc,  dest,  destpos) 
else  eightlittle(src,  srcpos,  endsrc,  dest,  destpos) 
where  eight  <| 

{m:nat,  n:nat,  endsrc :nat,  srcpos :nat,  destpos :nat  | 
endsrc  <=  m  /\  srcpos  <=  endsrc  /\ 

(endsrc  -  srcpos)  mod  8  =  2  /\  destpos  +  endsrc  -  srcpos  <=  n  } 
array(m)  *  int(srcpos)  *  int(endsrc)  *  array(n)  *  int(destpos)  ->  unit 

fun -(srcalign : nat} 

semialigned(src ,  srcpos,  endsrc,  dest,  destpos,  srcalign,  bytes)  = 
let 

val  front  = 

(case  srcalign  of 
0  =>  2 
I  2  =>  0 

I  1  =>  1 

I  3  =>  3)  <|  [i:nat  |  (srcalign  =  0  /\  i  =  2)  \/ 

(srcalign  =  2  /\  i  =  0)  \/ 

(srcalign  =  1  /\  i  =  1)  \/ 

(srcalign  =  3  /\  i  =  3) 

]  int(i) 

val  rest  =  bytes  -front 
val  tail  =  (rest  -  2)  mod  8 
val  middle  =  rest  -  tail 
val  midsrc  =  srcpos  +  front 
val  middest  =  destpos  +  front 
val  backsrc  =  midsrc  +  middle 
val  backdest  =  middest  +  middle 
in 

unaligned(src ,  srcpos,  midsrc,  dest,  destpos); 
eight (src,  midsrc,  backsrc,  dest,  middest); 
unaligned(src ,  backsrc,  endsrc,  dest,  backdest) 

end 

where  semialigned  <| 

{m:nat,  n:nat,  srcpos :nat,  endsrc :nat,  destpos :nat,  bytes :nat  | 
endsrc  <=  m  /\  srcpos  +  bytes  =  endsrc  /\ 
destpos  +  bytes  <=  n  /\  16  <=  bytes  } 
array (m)  *  int (srcpos)  *  int (endsrc)  * 

array (n)  *  int (destpos)  *  int (srcalign)  *  int (bytes)  ->  unit 


fun  copy (src,  srcpos,  bytes,  dest,  destpos)  = 
if  (bytes  <  25)  then 
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common(src,  srcpos,  srcpos  +  bytes,  dest,  destpos) 
else 

let 

val  srcalign  =  srcpos  mod  4 
val  destalign  =  destpos  mod  4 
val  endsrc  =  srcpos  +  bytes 
in 

if  srcalign  =  destalign  then 

aligned(src,  srcpos,  endsrc,  dest,  destpos,  srcalign,  bytes) 
else  if  (srcalign  +  destalign)  mod  2=0  then 
semialigned(src ,  srcpos,  endsrc,  dest, 
destpos,  srcalign,  bytes) 

else  unaligned(src ,  srcpos,  endsrc,  dest,  destpos) 

end 

where  copy  < | 

{mmat,  n:nat,  srcpos mat,  bytes :int,  destpos mat  | 
srcpos  +  bytes  <=  m  /\  destpos  +  bytes  <=  n  } 
array(m)  *  int(srcpos)  *  int(bytes)  *  array(n)  *  int(destpos)  ->  unit 
end  (*  end  of  the  structure  BCopy  *) 
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